The GDPR and your practice

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

The short version

With clients you work with data concerning health — anamnesis, allergens, photographs of the scalp. That is a special category of data under Article 9 GDPR and deserves the strictest handling. Tricho.app is built to guarantee, to you and to your client, that only you see the data: it is encrypted directly on your device and the server receives only unreadable encrypted content. That does not, however, lift the controller's duties off you. This page is the list of what remains with you.

Who is who

• You are the controller of your clients' data. You decide what you record, why, and how long you keep it.
• The operator of Tricho.app is your processor — it holds only the encrypted form of the data and has no key. Even if it wanted to, it could not read your records. What exactly the server sees (sizes, times, counts) is in the privacy policy.

1. The client's consent — the basis of everything

Start from what Article 9(1) says: it prohibits the processing of data concerning health. So you have to fit within one of the exceptions in paragraph 2 — and in practice you have a single realistic one.

The door that people think is open is not open. The exception for health professions (Article 9(2)(h)) does not apply to trichologists and hairdressers in Czechia. Trichology and hairdressing are not a health service under Act No. 372/2011 Coll. — they are trades; you are not a healthcare worker under Act No. 96/2004 Coll. nor a member of any chamber; and Act No. 110/2019 Coll. does not impose on you the professional secrecy on which the exception would rest (the general duty of confidentiality from § 15 of the old Act No. 101/2000 Coll. was not carried over by the new regulation). Do not rely on point (h) just because you record something that looks medical.

The realistic basis is therefore the explicit consent of the client (Article 9(2)(a)). Explicit consent is more than ordinary consent: besides having to be freely given, specific, informed and unambiguous, it must be given by an express statement — a signed paper or a tick box with text, not “she came and did not object”. You must be able to demonstrate it (Article 7(1)) and the client can withdraw it at any time, as easily as she gave it (Article 7(3)).

You have the finished text ready. In the client consent template (Czech) there is everything listed below, ready to print — including a separate sentence on photographs and an optional sentence on teaching. Print it, fill in your name and company ID, have it signed, and file the paper.

And record it in the card. The client's card has a record of consent to processing: whether she gave it, when, in what form (paper, e-mail) and whether she withdrew it. That record is your demonstrability under Article 7(1) — paper gets lost, the card does not. But you do not get to throw the paper away: the record in the card says that consent exists, it is not the wording of the consent itself.

Consent has to be freely given, specific, informed and demonstrable. Let it cover:

• who processes the data — you, by name and company ID;
• what you record — anamnesis, allergens, notes on the condition of the scalp, photographs;
• why — keeping the client's card and tracking development between visits;
• where it is stored — in the app on your device, encrypted; and whether you sync it between your devices through the operator's server (if you have Pro or Max, say so — it is a transfer to a processor);
• how long you will keep it;
• that she can withdraw consent at any time and how she does it, and that withdrawal does not affect what you processed before.

Keep the consent in writing — a signed paper or an e-mail from the client. Oral consent is valid, but you cannot prove it, and the burden of proof is on you.

Photographs have a regime of their own on top of that. A person's likeness is protected by the Civil Code (§ 84–90) separately, alongside the GDPR — and meeting the GDPR does not relieve you of this duty. For every photograph of the scalp you need permission to take and to use the likeness, even when you already have consent under the GDPR. Say clearly what the photos are for: only for the card, or for teaching as well. Permission can be withdrawn, and if the client withdraws it, she may claim damages from you if you relied on its continuing — the GDPR has no such rule and people overlook it.

2. Consent to use for teaching and case studies

In the client's card there is a field Consent to use — a tick box “The client agrees to the use of her case for teaching and case studies”, a date and a field To what extent (for example “without photos of the face”).

It is a separate consent for a separate purpose. Taking a case out of the card — into a lecture, a case study, an article — is not the same as keeping a card. It is a new purpose and needs its own basis. When you export a case without recorded consent, the app warns you and does not stop the export: the decision is yours, but it should not be unwitting. The state of consent is written into the exported story.

Anonymisation is not a substitute for consent as long as the client can be recognised from the photo or the description — and with the scalp she often can.

3. Records of processing activities (Article 30)

You must keep this record, even if you are a sole trader without employees. The exception for organisations under 250 employees (Article 30(5)) does not apply to you, and does so twice over: it excludes itself as soon as special categories of data under Article 9 are processed — that is, whenever you keep an anamnesis — and second because the processing is not occasional but takes place with every client at every visit. The number of employees changes nothing.

What such a record looks like when kept by the operator of the app, we are glad to show on its own — write for it to [email protected]. Yours will be shorter, but it should have the same columns.

It is one sheet of paper or one file. It is not sent anywhere; you have to show it if the Office for Personal Data Protection (ÚOOÚ) asks for it. At a minimum it should contain:

• your name, company ID, address and contact;
• the purpose of processing — “keeping the client's card and records of visits”;
• the categories of data subjects — “clients” — and the categories of data — “identification and contact data, data on the health of the scalp, anamnesis, allergens, photographs”;
• the categories of recipients — “the operator of Tricho.app as a processor (encrypted data)”; you pass the data to nobody else;
• transfers outside the EU/EEA — as a rule none in your case;
• time limits for erasure — how many years you keep the card;
• a general description of security — “encryption on the device, device lock, an updated system, a recovery code stored away from the device”.

When you organise events

Event registrations are a separate activity and belong in the record as another row. A template — fill it in and adjust it to how you really run your events:

You give co-attendees the information on processing under Article 14 GDPR: the app sends it to them by e-mail if the registrant gave their address, otherwise you give it to them at the event at the latest.

4. Data protection officer and impact assessment

• You do not have to appoint a data protection officer (DPO). The duty applies to public authorities and to large-scale, systematic processing; a solo practice does not fall under it.
• You do not have to carry out a data protection impact assessment (DPIA). The processing does not match the types for which the ÚOOÚ requires one. But write that conclusion down somewhere — two sentences with a date, in the folder with the record under Article 30. It is easier to demonstrate that you decided about it than to prove it retroactively. The operator did this for itself; we will send you its final report on request, and you can take the criteria and the line of reasoning from it as a model.
• For events with payments and bank notifications it is different: there the operator did carry out an impact assessment for itself (unrelated payers, a sub-processor in the USA that briefly reads the message). It makes the part describing the processing on its side available to you under Article 28(3)(f) GDPR — ask for it. Whether you need an assessment of your own is your decision; its material will help you.

5. Processing agreement

With a processor you must have a written contract under Article 28. You have a template ready here — print it, fill in your details, sign and file it. It is based on the European Commission's standard contractual clauses, so the ÚOOÚ will find its way around it.

6. A personal data breach — 72 hours

A lost unlocked phone with the card file, a stolen laptop, sending photos to the wrong recipient — all of these are personal data breaches. You have 72 hours from the moment you learned of it to notify the Office for Personal Data Protection. If you cannot make it, notify it later anyway and say why.

Beware of a trap: the form on the ÚOOÚ website is not submitted. You fill it in, it generates a PDF for you — and you have to deliver that through a data box (datová schránka), by post, or by e-mail with a recognised electronic signature. Otherwise the submission is not complete and the time limit keeps running. If you do not have a data box, get one before you need it.

When a breach occurs on the operator's side, the operator will let you know without undue delay, and it is you who then notify the ÚOOÚ — you are the controller. Document every breach, including the one you do not notify (Article 33(5)).

Encryption removes one duty, not both. Under Article 34(3)(a) you do not have to inform the clients of a breach if the data concerned were unintelligible — and the contents of the cards on the server are unintelligible. This does not, however, apply to technical data that is not encrypted (how many records you have, when you touched them), and the duty to notify the authority does not lapse at all. The risk does not disappear entirely either: a breach is also a situation where the data stay whole but cannot be restored — a loss of availability is a breach in itself.

7. How long to keep a card

You have no statutory period here. The healthcare services act does not apply to you and the hygiene operating rules speak of something else. So “five years, because that is how it is done” does not apply — you set the period according to your purpose and the scope of consent, and it should be as short as possible, but long enough for you to compare development between visits. Write it into the record under Article 30 and tell it to the client in the consent. And then keep to it — delete data you no longer need.

Only tax documents — invoices and receipts — have a fixed statutory period. How many years is set by the tax regulations according to your regime (ten years for a VAT payer), and it applies regardless of the client's card.

8. How to delete

In the client's card you have two different deletions. “Delete” only hides the card — the data stay and can be brought back; it is good for tidying the diary, it is not erasure under the GDPR. “Delete permanently” is irreversible: the card, visits and photographs disappear from your device and from the server, and your other devices delete them as soon as they connect. The app makes you type the word SMAZAT (“delete”) before it does it.

Where permanent deletion does not reach

To say it plainly — the app writes this on the screen before it deletes anything:

• Cloud backups that have already been made still contain the client. In the Pro plan 12 months, in Max 5 years. Then they expire by themselves. Deleting a single client does not reach into them. When you delete the whole account, the backups disappear with it.
• A device that is offline at the moment deletes her only when it connects. If you never turn it on again, she stays on it.
• Backups of the whole server — the server is backed up to separate storage outside its own disk (Oracle Object Storage, the same provider and region), in case of a disk or application failure. Snapshots are kept as 30 daily, 12 monthly and 2 yearly ones, so the oldest is up to two years old. Deletion does not reach into those at all: they run out and expire by themselves. This applies to deleting the whole account too. More in the privacy policy.
• An empty trace remains of her — just the record id without content, by which the other devices recognise what to delete. And a record that deletion took place: a date and a count, no names, no content.

If a client asks you for erasure, these four points are the part of the answer that is not worth trying to get around.

9. What else remains with you

• Inform the client under Article 13 — who you are, what you record, why, for how long, what rights she has and that she can complain to the ÚOOÚ. The consent and this information can be written on a single sheet.
• Handle her request for access, rectification or erasure within one month.
• Decide what goes to Google. When you connect Google Calendar and turn on the mirroring of appointments in the “With the client” mode, the client's name is written into your calendar at Google. That is a transfer of data that you decide on as the controller: it belongs in the information for the client and in your record under Article 30 (recipient Google, transfer to the USA). The “Busy only” mode does not pass the name on. Anamnesis, allergens, notes and services never go to Google.
• Secure your own device: a phone lock, an up-to-date system, a recovery key stored somewhere other than the device. The most common data leak in a small practice is not a hacker — it is a phone left on the counter.

What you can tell the client

“I keep your card in an app that encrypts everything directly on my phone. Nobody but me can get to it — not even the maker of the app.” That is true literally, not a marketing shortcut. What a client tells you stays between you.

How we, as the operator, handle data, you can read in the privacy policy.

Version 2026-10-31.