Personal Data Processing Agreement

This is a translation. The Czech version is binding. · Čeština

A template to print: fill in your details, sign it and file it with your contracts — more on this on the GDPR page.

concluded under Article 28(3) of Regulation (EU) 2016/679 (GDPR). Its structure and wording are based on the standard contractual clauses between controllers and processors under Commission Implementing Decision (EU) 2021/915.

The parties

Controller: ……………………………………………… (name / business name), company ID (IČO) ………………, seat ………………………………………………, e-mail ……………………………………………… (the “controller” — a trichologist or hairdresser using the Tricho.app application)

Processor: Ing. Jan Beránek, company ID (IČO) 88869709, seat Brozany 194, 533 52 Staré Hradiště, e-mail [email protected] (the “processor” — the operator of the Tricho.app application)

1. Purpose and scope

This agreement governs the processing of personal data that the processor carries out for the controller in providing the Tricho.app application. It applies alongside the terms and conditions; in case of conflict this agreement prevails. The annexes are an integral part of it.

2. Subject matter, duration, nature and purpose of the processing

• Subject matter: storing and transferring the data of the Tricho.app application between the controller's devices, and backing it up.
• Nature of the processing: storage, replication, backup and erasure — always exclusively in encrypted form. The processor does not hold the encryption key and has no access to the content; it therefore cannot perform any operation that would read the content of the data.
• Purpose: synchronising data between the controller's devices and providing encrypted backups within the scope of her plan.
• Booking (Objednávání) (all plans): receiving the booking envelope from the controller's client, delivering it to the controller's app, carrying out her commands (confirm, decline, move, cancel), sending messages to the client, and erasure under Annex A. The content of the envelope is encrypted to the controller's key and the processor does not open it. A booking is a distance contract between the controller and her client, so the processor also publishes the controller's identification as the seller, sends the client the confirmation with the booking terms, the withdrawal information and the model form, and runs the “Withdraw from the contract” form: it delivers the withdrawal statement, sealed in the browser to the controller's key, to her app, and uses the name, order number and e-mail that the person withdrawing types into the form only transiently, to send her the acknowledgement of receipt required by § 1830a(5) of the Czech Civil Code. Whether the withdrawal is valid and what happens to the appointment is decided by the controller's app, not by the processor.
• Events (Akce) (Max plan) and deposits in Booking (Pro and Max plans): publishing an event the controller prepares and holding seats; receiving the registration envelope from a participant and delivering it to the controller's app; sending messages to participants (confirmation, payment request, reminders, the Article 14 GDPR notice to co-attendees, waiting-list offers, cancellation, transfer, substitute) and to clients with a deposit; payment fingerprints and their matching; receiving bank notifications through Cloudflare and sealing them to the controller's key (optional); creating a card payment on the controller's Stripe account and a card refund on her instruction (optional, Article 4b); delivering documents by e-mail; erasure under Annex A. The content of a registration is sealed to the controller's key and the processor does not open it. The settings of an event (cancellation rules, deadlines, reminders, waiting list, discount codes) are the controller's instructions under Article 28(3)(a) GDPR.
• Money: the processor does not receive, hold or refund by itself the money of participants or clients. Payments go directly to the controller's account (her bank account or her Stripe account). Every refund is a task for the controller and happens only after confirmation from her device.
• Duration: for as long as the controller's account exists; it ends with the cancellation of the account or the termination of the contract under the terms and conditions.

3. Categories of data subjects and of personal data

• Data subjects: the controller's clients and the persons who send a withdrawal statement through the “Withdraw from the contract” form (even when they hold no appointment with the controller). For events, deposits and payments also event participants and their co-attendees, people on a waiting list, clients with a deposit in Booking, payers in bank notifications (including payers unrelated to Tricho.app) and contact persons of invoice buyers.
• Personal data: clients' identification and contact data, records of visits and the controller's notes. For a withdrawal the name, the order number or a description of the service and date, the e-mail for the acknowledgement and the time it was sent. For events, deposits and payments identification and contact data, billing data including the company ID (IČO) and VAT ID (DIČ), data on the registration, payment and attendance, and payment data (amount, variable symbol, payer's account, message for the payee and, with some banks, the balance of the controller's account).
• Special categories of data (Article 9): anamnesis, allergens, data on the condition of the scalp and photographs of it. No special categories of data are processed for events, deposits and payments; the note in a registration carries a hint not to enter health data.
• Clients' data are passed to the processor, and kept by it, exclusively in encrypted form. For events, deposits and payments the data are sealed to the controller's key or encrypted with the processor's key. What of all this the processor holds in readable form is described in Annex B.

4. The controller's instructions

The processor processes personal data only on the controller's documented instructions. The controller gives instructions by using the app (storing, editing, syncing, erasing) and further in writing to the processor's e-mail. The processor informs the controller without delay if it considers an instruction to infringe the GDPR or another data protection rule, and need not carry out such an instruction.

The processor does not process the data for its own purposes, does not pass it to third parties other than those in Annex C, and does not use it to train any models, for advertising or for analytics.

4a. Services you connect yourself

The controller may connect her own Google account (calendar and tasks) to her account. The controller's device then reads and writes events and tasks directly at Google; the processor writes no content to Google and does not see the content of those writes. If the controller turns on the mirroring of appointments in the “With the client” mode, she passes the client's name into her own Google account as the controller, from her device and on her own decision. Google is thereby not a sub-processor of the processor and the processor does not receive these data. Services, notes, allergens and anamnesis do not go to Google. For the connection the processor holds only the data described in the privacy policy (an encrypted access key, the e-mail of the connected account, identifiers of the blocking calendars and merged “busy” spans with only a start and an end); these are the controller's own data, not data of her clients.

4b. A Stripe account you connect yourself

A controller on the Max plan may connect her own Stripe account to her account (an existing account by signing in at Stripe, a new one through Stripe's guide) to accept card payments for events and deposits. The contract with Stripe is concluded by the controller; the money goes to her Stripe account and Tricho.app collects nothing from it (a 0 % application fee). For the payments of her participants and clients Stripe is the controller's processor under her contract with Stripe and, within the scope of its own obligations (fraud and money-laundering prevention, payment regulation), an independent controller. Stripe is not a sub-processor of the processor; it is listed in Annex C only for completeness.

The processor acts on the controller's Stripe account with a restricted key of the platform and only to this extent: it creates a payment (Checkout Session) with minimal data (the identifier of the registration or request and the public line item), reads the state of the account and of payments, and makes a card refund only on an instruction from the controller's device. It never refunds money by itself. A Stripe notification with the payer's data (e-mail, name, possibly address and telephone) passes through the server only in transit, is narrowed to the necessary fields at once and is neither stored nor logged, not even on error; notifications of payments unrelated to Tricho.app are dropped after the signature check. The processor keeps only the identifier of the connected account, its state and the identifiers of payments (Annex A); it does not store the amount, but can read it from Stripe at any time.

To be honest: the restricted platform key can technically read and write other objects on a connected account too. The processor does not use it for that and keeps it only in the server's encrypted secret store; its leak is a scenario of Article 10. A card payment reaches the controller's app through the server and so relies on its integrity. The controller can disconnect at any time in the app or at Stripe.

5. Confidentiality

The processor binds to confidentiality every person who takes part in operating the service and who could come into contact with the data or with technical data about it. The obligation continues after the cooperation ends.

6. Security of processing (Article 32)

The processor has put in place and maintains in particular these measures:

• Encryption on the controller's device. Content is encrypted with the AES-256-GCM algorithm using a key derived from a secret known only to the controller. The key does not leave the device and the processor does not have it — it cannot surrender it even on order.
• Binding of the encrypted content. Every encrypted record is cryptographically bound to the vault identifier and to the record identifier; it therefore cannot be moved unnoticed to another account or replaced by another.
• Encrypted transfer. All communication takes place exclusively over TLS (HTTPS).
• Access control. Only the processor has access to the server, on the basis of a key; every intervention on the server is carried out by a script kept in a version-controlled repository.
• Separation of accounts. Each controller has her own database; access is verified by a signed token and checked on every request.
• Backup and restore. Daily server backups with a regular restore test; retention of 30 daily, 12 monthly and 2 yearly snapshots.
• Operational logs without authorisation headers and without cookies, kept for a short rotation.

The processor is not responsible for the security of the controller's device or for how she handles her recovery key — those are measures on the controller's side.

7. Sub-processors

The controller gives the processor general authorisation to engage the sub-processors listed in Annex C. The processor:

• concludes with each sub-processor a contract that imposes on it obligations to an extent corresponding to this agreement;
• informs the controller of an intention to engage a new sub-processor or to replace an existing one at least 30 days in advance, by e-mail and by a notice in the app;
• allows the controller to object within the same period; if the objection persists and the parties do not agree, the controller may terminate the agreement free of charge and the processor refunds her a proportionate part of the subscription;
• is liable to the controller for the performance of the sub-processors' obligations as if it performed them itself;
• provides the controller on request with a copy of the arrangement with a sub-processor; it may redact commercial terms that do not concern data protection.

A sub-processor for an optional function only. The processor announces Cloudflare Email Routing and Workers (receiving bank notifications, Annex C) by the procedure of this article and engages them no earlier than 30 days after the announcement, and only for a controller who switches the function on herself. An objection of the controller to a sub-processor needed only by an optional function results in the function not being switched on for her, or being switched off; it does not block the change for other controllers. Matching payments from a bank statement on her device remains available to her. The right to terminate the agreement free of charge under the previous paragraph is not affected.

8. Transfers outside the EU/EEA

Encrypted content is stored on a server in the data centre Frankfurt nad Mohanem, Německo (Oracle Cloud, region eu-frankfurt-1), that is inside the EU/EEA; the contents of vaults are not transferred outside the EU/EEA. Some sub-processors under Annex C may also process data outside the EU/EEA; in that case the transfer relies on an adequacy decision or on the European Commission's standard contractual clauses. On request the processor will document which instrument applies to which recipient.

Bank notifications. With Cloudflare Email Routing and Workers (Annex C) the bank's message is readable, while it is processed, in the memory of the Worker, which may run anywhere in Cloudflare's network, including the USA; Cloudflare also keeps the sender, the recipient address and the subject of every message for 31 days. Here the transfer relies primarily on the Commission's adequacy decision (EU–US Data Privacy Framework), under which Cloudflare, Inc. is certified, and in support on the standard contractual clauses 2021/914, module 3 (processor to processor). Supplementary measures: the function is optional and importing a statement on the device stays the default path; the Worker logs nothing and stores no content, and seals the whole message to the controller's key at once; the secret address can be replaced at any time. If the Court of Justice of the EU annulled the DPF decision, the processor stops creating new addresses within 7 days and within 30 days moves the reception to its own server in the EU or switches the function off; the controller is told by e-mail and in the app.

9. Assistance to the controller

Taking into account the nature of the processing, the processor assists the controller:

• with requests of data subjects (Articles 12–22). Because it cannot read the content, it cannot handle a request itself. Access, rectification, export and erasure are performed by the controller directly in the app; the processor provides her with the tools, a description and technical support for this. If a data subject turns to the processor directly with a request, the processor passes it on to the controller without delay and does not respond to it itself;
• with the security of processing (Article 32) — by a description of the measures in place and of their changes;
• with the notification of breaches (Articles 33 and 34) — by the procedure under Article 10 of this agreement;
• with impact assessment and prior consultation (Articles 35 and 36) — by providing the information about the processing that it has available.

10. Notification of a personal data breach

The processor notifies the controller of every personal data breach concerning data processed under this agreement without undue delay after becoming aware of it, and at the latest within 48 hours, by e-mail to the address given for the account. The period is agreed this way so that the controller has time left for her own notification to the supervisory authority within 72 hours under Article 33(1). The notification contains a description of the nature of the breach, the categories and approximate number of records concerned, the likely consequences, the measures taken and proposed, and a contact for further information. If not all the information is available immediately, the processor provides it in phases, without further delay.

Two scenarios for events and payments belong here expressly: a leak of the Worker secret with which the Cloudflare Email Worker passes sealed bank notifications to the server (the secret is valid only for receiving these messages), and a leak of the restricted Stripe platform key, which affects every connected Stripe account. For both the processor notifies the breach to every affected controller without undue delay, replaces the key and describes what an attacker could have done with it.

The notification to the Office for Personal Data Protection within 72 hours and any communication to clients is made by the controller; the processor provides her with all available assistance for this. The processor documents every breach and presents the documentation on request.

11. Demonstrating compliance and audit

The processor provides the controller with all information necessary to demonstrate compliance with Article 28 GDPR and with this agreement.

The processor further allows for and contributes to audits, including inspections, conducted by the controller or an auditor mandated by the controller. Practical rules that do not narrow the right of audit: an audit is announced in writing at least 30 days in advance (for an audit following a security breach without this period), takes place during working hours, must not disproportionately disrupt operation, the auditor is bound by confidentiality and does not get access to the data of other customers. The costs of the audit are borne by the controller; if the audit finds a material breach of this agreement, they are borne by the processor.

Providing a description of the architecture and security documentation is a supplement to the right of audit, not a replacement for it.

12. Erasure or return of data after the end

After the end of the provision of the service, the processor, at the controller's choice, erases the data or returns it to her, and deletes existing copies, subject to the limitations stated below, which the controller expressly accepts as the agreed way of carrying out the instruction to erase. The controller communicates her choice within 30 days of the end; if she does not, the processor erases the data.

Return takes place by the controller exporting the data from the app in an open format, or downloading an encrypted backup; the processor cannot decrypt the content and therefore cannot hand it over in readable form.

Erasing the account removes the database with the encrypted data, the cloud backups, the records of devices and the sign-in tokens. The processor warns the controller in advance, and she agrees, that data may persist:

• in backups of the whole server until their rotation (30 daily, 12 monthly and 2 yearly snapshots — that is, for two years at most); snapshots cannot be intervened in without spoiling the restore for other customers;
• in cloud backups for the retention period of the plan (Pro 12 months, Max 5 years), where it is the erasure of an individual client and not of the whole account;
• on the controller's device that is offline, until it connects;
• as a record identifier without content and as a pseudonymous record that the erasure took place (a date and a count).

The data on events, deposits and payments held by the server are erased continuously under the periods in Annex A, independently of the end of the service. The database of payment fingerprints is not backed up, so it does not persist in the server backups.

After these periods have passed the data are removed; until then the processor does not use them except for a necessary restore, and they remain encrypted. The processor further retains documents that Union or Member State law requires it to retain — in its case, invoices (10 years). These contain no data of clients.

13. Breach and termination

If the processor breaches this agreement in a material way, the controller may terminate the agreement and the account; in that case the processor refunds a proportionate part of the subscription. If the processor is unable to perform its obligations under this agreement, it notifies the controller without undue delay.

14. Liability

The parties' liability for harm caused by the processing is governed by Article 82 GDPR. The limitation of compensation for harm agreed in the terms and conditions does not apply to claims of data subjects under Article 82 GDPR or to penalties imposed by a supervisory authority — not even where the controller is a business customer. To put it plainly: the ceiling that is in the terms does not cover what a client or an authority might claim from either party.

If one party compensates the harm in full, it may claim from the other the part corresponding to that party's share of responsibility (Article 82(5) GDPR).

15. Final provisions

The agreement is governed by the law of the Czech Republic and lasts for as long as the controller's account exists. If the conditions of processing change, the same procedure applies as for a change to the terms and conditions; the processor announces a material change at least 30 days in advance. The extension of the processing to Booking, events, deposits and payments is part of this template, including Annexes A to C; the extension to events, deposits and payments is a material change and the processor announced it at least 30 days in advance. A new version of the template or a change of the annexes is announced to the controller by the procedure under Article 7 (for sub-processors) and under this article (for other changes).

If this agreement is concluded electronically (by confirmation when the account is created), the requirement of written form is considered met under Article 28(9) GDPR, which expressly permits electronic form. The signature lines below serve the paper variant.

Annex A — Description of the processing

Annex B — What the processor holds in readable form

The content is always encrypted. So that the server can replicate and back up, it sees these technical data for each record:

• the record identifier, its type (client / visit / photograph) and the revision number;
• the time of the last change and a flag that the record was deleted;
• the size of the record, the size of each attachment, the total size of the database and the month the record falls into;
• the vault identifier (vaultId) in readable form.

From these data one can infer the number of clients and the time schedule of the controller's work; one cannot find out the identity of the clients or the content of the records.

With Booking switched on, the following is additionally readable: the free windows that the controller publishes (her workload can be inferred from them), the start and end of each booking's appointment and its status. The client's e-mail is held by the processor only encrypted with its own key that is not in the database, and only so that it can send messages to the client; the name, telephone, note and chosen services are in the envelope encrypted to the controller's key. The list of clients for whom Booking is permitted is held by the processor only as fingerprints from which the addresses cannot be read back; addresses from the controller's device do not leave it for this purpose.

Because a booking is a distance contract, it additionally carries the order number (derived from its identifier), the version of the terms and their hash, the time the contract was concluded, the end of the withdrawal period, the time of the request for performance within that period and a flag that it was cancelled because of a withdrawal. None of this says who made the booking. The controller's identification as the seller (name, registered office, company ID, register entry, telephone, e-mail, the VAT sentence) is part of her public profile, like her name.

The “Withdraw from the contract” form. The name, the order number (or the service and date) and the e-mail that a person types into it are readable to the processor only transiently, to compose the acknowledgement of receipt; it compares the order number with the controller's bookings in memory only. What stays stored is only the statement sealed in the browser to the controller's key, until the acknowledgement is delivered the message in the queue encrypted with the processor's key (at most 24 hours), and a marker against double receipt without content (30 days). The operational logs carry only the account identifier, the withdrawal identifier and the outcome. Seznam.cz reads the acknowledgement when it sends it, as every message to a client.

For events and deposits the following is additionally readable:

• the published event — title, description, place, dates and days with times, prices and price tiers, capacity, the cancellation scale, sales windows, status and audience, the seller's identification (name, address, company ID) and the text of the terms; the server gives all of this to anyone together with the number of free seats. The controller's receiving account is held only to compose payment instructions and is never shown publicly;
• taken seats with an opaque holder and expiry;
• for each registration its identifier, event and date, number of seats, status, deadlines, when and how it was paid, the state of the payment fingerprint, card payment identifiers, whether the payer attends, the source (sign-up or manual entry), the acknowledgement of the business declaration and the terms version, the class of a cancellation reason, per seat whether the Article 14 GDPR notice went out, and keyed fingerprints of the e-mail and IP address for limits. Not the variable symbol, the amount, the price tier or the discount code of a registration; the amount can however be derived from the public price, the number of seats and the code rule, and that is declared;
• discount codes: their rules, a fingerprint of the code and which registration used the code;
• the waiting list: order, state and offer expiry;
• refund tasks with dates and state, without an amount;
• the number of revisions of the shared document counter (roughly how many documents were issued online);
• for a request with a deposit the deposit state and deadlines, not the variable symbol or the amount (which can be derived from the service's public price and its deposit rule);
• the number of open payment fingerprints (padded with decoys to a multiple of five for invoices), the day of publication, a coarse expiry and which registration or request matched or is held;
• for card payments the identifier of the connected Stripe account, its state and payment identifiers; for bank notifications a fingerprint of the secret address (never the address itself), keyed fingerprints of the controller's accounts, switches and health times, and for each message a sealed envelope with its time, the bank's domain, a size class, the verdict and the matching outcome.

From these data one can infer how many registrations and unpaid receivables the controller has; one cannot find out who registered, how much she paid or who paid.

Under the processor's key (like a client's e-mail in Booking) are the e-mails of the registrant and of every co-attendee, the links for cancelling and viewing, the payment instructions of a registration or deposit (variable symbol, amount, account), the charged amount, price tier and code of a registration (until the end of the event's last day), the buyer's e-mail of an open invoice and the outgoing mail queue (at most 24 hours). Whoever obtained the database and the server's environment would read these data; they would not read the envelopes of registrations and bank notifications even then. The name, telephone, billing data, co-attendees' names and the note are in an envelope sealed to the controller's key and the processor never reads them.

Outgoing mail. Messages to participants and clients, including payment requests with the variable symbol, amount, account and QR code, are sent by Seznam.cz (Annex C), which reads them when sending. Where the service allows it, storing copies of sent messages is switched off; where it does not, a copy stays in the sender's mailbox at Seznam.cz in the Czech Republic and the processor uses it only to trace an undelivered message. The server's operational logs carry only counts and outcomes, never a fingerprint, variable symbol, amount or e-mail address.

Annex C — Sub-processors

Who is not a sub-processor. Google (also as the provider of the calendar and tasks that the controller connects herself — see Article 4a) and Apple in the role of sign-in providers, and Fio banka in the role of payment service provider, do not act under this agreement as sub-processors — in relation to the controller's data they act as independent controllers and have no access to the data of her clients. The same applies to Stripe within the scope of its own obligations in fraud prevention and anti-money-laundering; for card payments on the controller's Stripe account Stripe is her processor under her own contract (Article 4b). The controller's bank, which sends her the payment notifications, is an independent controller. The processor serves fonts from its own addresses, so not even a visitor's IP address reaches any third party.

The current list and scope is always also in the privacy policy.

Version 2026-10-31. Effective: 31 October 2026.