Privacy Policy

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

The short version

The diary, clients, photographs and notes are encrypted on your device with a key that we never receive. The server holds only the encrypted content — and, with it, technical data about it: how many records, how large, when last changed. Not what is written in them.
About you we know what we need for the account and the invoice: the identifier from the Google or Apple sign-in (including the name and profile photo, as the provider passes them to us), e-mail, subscription status, receipts.
No analytics. No Google Analytics, no Facebook Pixel, no tracking scripts. (more about cookies)
No automated decision-making or profiling.
You connect Google Calendar and Google Tasks only if you want to. Event titles and tasks are read and written by your device directly at Google; our server knows only the “busy” times. We do not sell data from Google, nor use it for advertising or for training artificial intelligence. (in detail)
We process your clients' data only as your processor — you are the controller. (what that means for you)
The same holds for event participants and clients who pay in advance. Here, though, the server sees more than for the card file — the state of registrations, deadlines, e-mails encrypted with its key — and for bank notifications Cloudflare reads the message for a few seconds. We list it all. (in detail)

Two roles, two parts

This text has two parts, because the operator acts in two different roles and has different duties in each:

Controller — for data about you and your account (sign-in, subscription, invoices, operational logs). Here we decide, and we inform you under Article 13 GDPR.
Processor — for the data of your clients (anamnesis, allergens, photographs, notes). Here you decide; we only store and transfer it, and only encrypted. The rules of this role are described by the processing agreement.

1. The operator as controller — data about you

The controller of this data is Ing. Jan Beránek, company ID (IČO) 88869709, with its seat at Brozany 194, 533 52 Staré Hradiště. Contact: [email protected]. We have not appointed a data protection officer — we do not meet the conditions of Article 37 GDPR for mandatory appointment. Ask directly at the e-mail above.

What we process and why

Data	Purpose	Legal basis	How long
Identifier from the sign-in with Google / Apple: a permanent account identifier, e-mail and — as the provider passes them to us — name and profile photo; also the name of the provider, the date the account was created and the last sign-in	Sign-in, account management, communication about the account	Performance of a contract (Article 6(1)(b))	Until the account is deleted
Credentials to your sync database (a generated CouchDB user name and password) and hashes of the devices' sign-in tokens — the tokens themselves are not stored, only their hash, by which the server recognises a valid token without being able to use it again	The technical basis of synchronisation and device sign-in	Performance of a contract	Until the account is deleted; a token hash until it expires or the device is signed out
Records of your devices (device name, when it was added and last seen, device identifier)	The device limit under the plan, the ability to sign out a lost device	Performance of a contract	Until the device is removed or the account deleted
Subscription status (plan, paid until, payment status) and records of payments; for a transfer the amount, variable symbol and account number, as the bank passes them to us	Providing paid features, matching payments	Performance of a contract	Until the account is deleted
The connection of your Stripe account, when you connect it for events and deposits (Max plan): the account identifier, whether it may accept payments, whether it is in live mode, the way and state of the connection. We read the account name from Stripe live and do not store it	Offering card payment to your account for your events and deposits	Performance of a contract	While connected; disconnecting, revoking access at Stripe or deleting the account erases the record
Invoices and accounting documents (Stripe)	Statutory duties in accounting and taxes	Legal obligation (Article 6(1)(c)) — the income tax act, the VAT act and the tax code	For the period that the tax rules prescribe — at most 10 years from the end of the tax period. Not even deleting the account shortens this period
Server operational logs (IP address, time and target of the request, return code). The `Authorization`, `Cookie` and `Set-Cookie` headers are not written to the log.	Operational security, finding errors, defence against attacks	Legitimate interest (Article 6(1)(f)) — operating the service securely; you may object to this processing	Short-term. Logs are kept in a rotating buffer of about 30 MB and the oldest are overwritten by new ones; how fast depends on traffic — at today's traffic, in the order of days to weeks
The encrypted content of the app and technical data about it — see part 2	Synchronisation and cloud backups	Performance of the contract with you; for the content we are a processor	Until the account is deleted; backups according to the plan's retention
The e-mail entered in the “Let me know” form on the home page	A message when something substantial is added to Tricho.app	Consent (Article 6(1)(a)) — you withdraw it with the unsubscribe link in every message	Until consent is withdrawn
A backup of the whole server (restic snapshots). It contains everything above in the form in which it was on the server — so also the technical data in readable form and the file names of monthly backups, which carry your user name.	Recovery after a disaster	Legitimate interest — not losing customers' data	30 daily, 12 monthly and 2 yearly snapshots. A deleted item can therefore survive in a backup for up to 2 years until rotation pushes it out.
A record of account deletion (when the deletion took place and that it was a deletion at your own request, against a pseudonymous account identifier). Without a name, without an e-mail, without content.	To demonstrate that we carried out the erasure (Article 5(2))	Legitimate interest — demonstrability	Survives the deletion of the account for as long as it is needed to demonstrate the erasure

We never see your payment card number — the whole card payment is processed by Stripe on its own pages. For a bank transfer we see the data about the incoming payment, as the bank passes them to us.

Billing data is deliberately not in the encrypted vault: tax documents must be readable for the tax administrator. The vault is for clients, not for invoices.

2. The operator as processor — your clients' data

Anamnesis, allergens, photographs of the scalp and your notes are the data of your clients. You are the controller. We process it exclusively on your instructions, which you give by the way you use the app. The conditions of this role are in the processing agreement (Article 28 GDPR).

The legal basis on your side. This is data concerning health, a special category under Article 9 GDPR. The exception for health professions (Article 9(2)(h)) does not apply to trichologists and hairdressers in Czechia — they are not healthcare providers, and the law does not impose on them the professional secrecy on which the exception would rest. The realistic basis is therefore the explicit consent of the client (Article 9(2)(a)). What the consent should contain is set out by the GDPR page; a ready text to print is in the consent template (Czech). In the client's card the app lets you record when she gave consent, in what form and whether she withdrew it — demonstrability under Article 7(1) is yours to provide, and this is the place to keep it.

What the server actually sees of this content

The content is encrypted on your device (AES-256-GCM) and the key is not with us. But the server is not entirely blind — so that it can replicate and back up, it sees:

the record identifier, its type (client / visit / photo) and the revision number;
the time of the last change and a flag that the record was deleted;
the size of the record and 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 — this is what binds the encrypted content to your account.

From this one can infer how many clients you keep and when you work. One cannot find out who they are or what you have written about them. We say it this precisely on purpose — “we see nothing” would be a nicer sentence, but it would not be true.

Booking — when a client picks an appointment herself

In every plan you can switch on Booking (Objednávání): your client opens your link, confirms her e-mail with a one-time code and picks a free slot. On Free you can thereby allow up to 5 clients, on Pro 20, on Max as many as you like, and only on Max can you open the page to anyone with the link. The content of the booking — name, e-mail, telephone, note and the chosen services — is encrypted to your key by her browser before anything leaves. We do not open it; only you read it, in the app. You are the controller, and we act as your processor.

The server readably knows only this:

the free windows that the app publishes — from the complement to your working hours one can infer how busy you are, not who was with you;
the start and end of the appointment and the status of the booking (waiting, confirmed, declined, expired, cancelled);
the client's e-mail — transiently when entered, so that the code reaches her, and at booking stored only encrypted with the server's key, so that we can send her the confirmation, cancellation and a reminder 24 hours before. The key is not in the database;
keyed fingerprints of the client's e-mail and IP address, from which neither the address nor the IP can be read back; they serve only to limit the number of codes and bookings.

The list of permitted clients. We send a code only to an address that you saved on the client's card and permitted. The addresses of this list do not leave your device: the app makes a fingerprint of each (a salted, keyed hash) and sends only the fingerprints to the server. We encode them once more with a secret key that is outside the database, so the addresses cannot be read back from the list. We know only how many items the list has and whether the page is open to anyone or only to the permitted.

Messages that we send to you (“You have a new booking”) contain no data of the client. Messages to clients are sent by Seznam.cz (Email Profi). The request for a code is protected by Cloudflare Turnstile — it sees the client's IP address and browser details, not her e-mail or the booking.

How long. An unconfirmed booking expires after 48 hours (you can set this), at the latest 24 hours before the appointment. A finished booking loses its encrypted e-mail and content after 7 days; the whole one is deleted 30 days after the appointment. Verification codes are deleted after they expire, counters after 24 hours.

Who is responsible for what. For the content of the booking and for messages to the client we are your processor; the client turns to you as the controller, and the legal basis on your side is steps taken at her request prior to entering into a contract (Article 6(1)(b)). The keyed fingerprints and counters that prevent abuse of the form we keep as an independent controller on the basis of the legitimate interest in secure operation (Article 6(1)(f)). The client finds a brief version of these rules directly on your Booking page, in the “Privacy” link.

Events, deposits and payments

On the Max plan you can publish an event (a course, a workshop) and participants register for it on your public page; on the Pro and Max plans you can ask for a deposit for a slot in Booking. You are the seller and you are the controller of the participants' and clients' data; we act as your processor under the processing agreement. The money goes straight to your account — we collect nothing from payments and refund nothing by ourselves.

The name, telephone, billing data, co-attendees' names and the note of a registration are sealed by the participant's browser to your key; we do not read them. For events the server does see more than for the card file, so we say it in full: the published event, taken seats, for each registration its status, deadlines, when and how it was paid, and keyed fingerprints of the e-mail and IP for limits; it keeps the e-mails of the registrant and co-attendees and the payment instructions encrypted with its own key, so that it can send confirmations, payment requests and reminders. It does not store the variable symbol or the amount of a registration in readable form. The full list is in Annex B of the processing agreement.

Bank notifications (optional, Max). When you switch them on, your bank sends notifications of incoming payments to your secret address. They are received by Cloudflare Email Routing, whose Worker reads the message in memory for a few seconds — including payments unrelated to events and, with some banks, the balance —, computes payment fingerprints, seals the whole message to your key and discards the original. For each message Cloudflare stores the sender, the recipient address and the subject for 31 days; it does not store the content. This cannot be switched off, which is why we say it this plainly. Importing a statement, matched only on your device, stays the default path. We switch the function on no earlier than 30 days after announcing the new sub-processor.
Card payment (optional, Max) runs on your own Stripe account under your contract with Stripe. The payer's data that Stripe sends in a payment notification pass through the server only in transit and are not stored; we make a card refund only on your instruction from your device.
How long. We erase the e-mails and links of registrations at the end of the event's last day; 30 days later the rest of a registration shrinks to a status record without contact. Payment fingerprints are kept in a database that is not backed up. A sealed bank notification is erased 30 days after it is resolved on your device, otherwise after 90 days.
Protecting the event page. The Cloudflare Turnstile check (IP address and browser details), keyed fingerprints of the e-mail and IP and attempt counters are kept by us as an independent controller on the basis of a legitimate interest in safe operation (Article 6(1)(f)); counters for 24 hours, fingerprints until the contact is erased at the end of the event.

The rules you set for an event (the payment deadline, releasing an unpaid seat, the order of the waiting list) are applied by the app automatically according to your settings; a participant can turn to you, and you can change any such decision manually in the app at any time. Participants find a short privacy notice directly on the event page.

Statements, receipts and sales recording

Bills, receipts, the price list and the sales-recording settings are part of your encrypted vault, just like clients' cards. A receipt (PDF) is created on your device. Two things from it, however, do go out, and only when you yourself ask for it:

A receipt by e-mail to the client. When you send a receipt by e-mail, the device hands to our server the finished PDF, the text of the message, the client's address and the name of your premises. The server immediately passes the message on for sending (Seznam.cz, Email Profi) and keeps nothing — no copy, no address in the database or in the logs; the operational log gets only the fact that the message went out and its size. It is the only place where content from your vault passes through our server readably, and that is why it is voluntary: in the client's card you record that she agreed to receive receipts by e-mail. We act here as your processor.
Sales recording (EET). When you turn it on, your device sends the sale data directly to the Financial Administration: your recording number (EIČ), the designation of the premises and device, the receipt number, the time and the amount. Nothing about the client. Our server does not see these messages. The certificate for recording and its private key lie only in your encrypted vault. The Financial Administration is here a recipient to whom you, not we, pass the data by law.

Google Calendar and Google Tasks — when you connect them

Connecting Google is voluntary. You connect it yourself in the app (Settings → Google Calendar) or in My account on the website; you give your consent to Google in the browser. The connection belongs to your account, so it serves all your devices, and disconnecting ends it on all of them. Without it Tricho.app works unchanged. It serves so that:

your events and tasks from Google show up in the diary;
you can create, change and delete events and tasks in your Google from the diary;
Booking does not offer a time when you already have something else;
your appointments from Tricho.app are optionally written to the “Tricho.app” calendar (mirroring).

For this data we are the controller — it is data about you and your Google account. The legal basis is performance of a contract at your request (Article 6(1)(b)): by connecting you order the service, by disconnecting you end it at any time.

Which permissions we ask for

Google permission	What for	Required?
`calendar.calendarlist.readonly`	The list of your calendars, so that in the app you choose which ones show in the diary and which ones block Booking	Yes
`calendar.events.readonly`	Reading events: on the device the title and time for the diary, on the server only the start, end and status for guarding free slots	Yes
`calendar.events.owned`	Creating, editing and deleting events in calendars that you own — only when you do it in the diary	No, you can untick it at Google
`tasks`	Showing Google Tasks in the diary, creating, editing, ticking off and deleting them — only when you do it	No
`calendar.app.created`	The “Tricho.app” calendar, which the app creates itself for mirroring appointments; it does not reach any other calendar through this	No

When connecting we also receive the e-mail of the Google account, which we show in My account so that you know what is connected.

What your device reads and writes

Event titles, calendar names and tasks are fetched by the app directly from Google and kept only in the device's memory; they disappear when the app is locked. Writes (a new event, an edit, a deletion, a task, a mirrored appointment) are sent by your device directly to Google, and only when you do something in the app. Before a write is sent — for example when you are offline — it waits in a queue on the device, encrypted with your key. None of this goes to our server. For access to Google the device uses a short-lived access token that our server issues to it and that expires after an hour.

What our server does

The server holds your long-term access key to Google (the refresh token) encrypted with a server key that is not in the database, and every few minutes asks Google about the calendars that you marked as blocking. It asks expressly only for the start, end and status of an event and for whether you declined the invitation — it does not read or store titles, descriptions, places or other attendees. From the answer it computes “busy” spans so that Booking does not offer a time when you already have something else.

The server does not write to Google. But we say openly what it technically could do: the access key would suffice also for reading titles and — if you granted the optional permissions — for writing. That it does not is a rule in the code, guarded by automated tests, not a cipher.

When the connection expires (you withdraw access at Google) and you have calendars that block Booking, online booking stops until you connect again — better to offer nothing than a double booking.

Mirroring appointments to the “Tricho.app” calendar

Mirroring is off by default. You turn it on in Settings → Google Calendar and choose from two modes:

Busy only — only the time of the appointment with the title “Busy” goes to Google.
With the client — the client's name goes to Google as well. Google will see it, and everyone with whom you share the “Tricho.app” calendar.

Services, notes, allergens and anamnesis never go to Google, in any mode. The client's name in the “With the client” mode is passed to Google by you as the controller of her data, from your device into your Google account. Our server does not see it and we do not process it; what this means for informing clients is on the GDPR page.

Where things are stored and for how long

On the server: the encrypted access key, the e-mail of the connected account, identifiers of the calendars that block Booking (at Google these tend to be an e-mail address), and “busy” spans from now to the end of the Booking horizon (60 days by default). The spans are overwritten with every query to Google; we do not keep older ones. All of it applies until you disconnect or the account is deleted.
On your device: event titles and tasks only in memory, until the app is locked; unsent writes encrypted until they are sent; your choice of calendars and of the mirroring mode in the encrypted vault.
At Google: the events, tasks and the “Tricho.app” calendar that you created. They are yours and are governed by Google's terms.

Disconnecting and deleting

You can disconnect at any time in the app (Settings → Google Calendar) or in My account. This deletes from the server the connection and all stored times, and the access key is invalidated at Google.
When the account is deleted, the connection and the stored times are deleted too.
The “Tricho.app” calendar and the events or tasks that you created in Google remain at Google after disconnecting. By turning off mirroring the “Tricho.app” calendar is deleted automatically; otherwise you delete it in Google Calendar on the web (Settings → calendar → Delete).
You can also revoke access directly at Google: in the Google account settings, in the section on security and third-party app access (myaccount.google.com/permissions). Tricho.app notices this and marks the connection as expired.
A server backup (see the table above) may hold deleted data for the duration of the backup rotation; the access key is in it only encrypted and, after disconnecting, no longer valid at Google.

Limited use of data from Google

The data that Tricho.app obtains from Google interfaces (Google Calendar and Google Tasks) we use only for the features described above, which you see and use: the diary, the writes you make in the app, mirroring appointments and guarding free slots for Booking. Specifically:

we do not sell it and we do not pass it to anyone — except where the law requires it, or where it is necessary to protect the security of the service;
we do not use it for advertising, for targeting advertising, for assessing creditworthiness or for any purpose other than the one for which you connected it;
we do not use it to create, train or improve artificial intelligence or machine-learning models;
no human at our end reads it — unless you yourself expressly ask us to (for example when troubleshooting), it is necessary for security (investigating abuse) or the law requires it. Event titles and tasks do not reach us at all, by the way.

Tricho.app's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. The use of information received from Google Workspace scopes will adhere to the Google Workspace API User Data and Developer Policy, including the Limited Use requirements. Tricho.app does not use Google user data to develop, improve or train generalized or non-personalized AI or ML models.

Whom we pass data to

Only to processors and recipients without whom the service does not work. We sell the data to nobody and share it with nobody for advertising.

To whom	What for	What reaches them
Cloudflare (Cloudflare Pages)	Delivering the website `dev.tricho.app` and the app `app.dev.tricho.app`	The IP address and technical data about the request. Encrypted content does not pass through Cloudflare.
Cloudflare (Turnstile, Pages) — only for Booking and events	Verifying that a human is sending the request for a code on the public page or event page; delivering those pages	The IP address and browser details of the client or participant. Not the e-mail or the content of the booking or registration.
Cloudflare (Email Routing and Workers) — only when you switch on bank notifications	Receiving bank notifications, verifying the bank's signature, computing payment fingerprints and sealing the message to your key	The whole bank notification in memory for a few seconds, including unrelated payments and, with some banks, the balance; the sender, recipient address and subject for 31 days.
Oracle Cloud	The server for synchronisation, backups and sign-in (`sync.dev.tricho.app`)	Everything that is on the server: encrypted content, data about the account and subscription, operational logs. Data centre: Frankfurt nad Mohanem, Německo (Oracle Cloud, region eu-frankfurt-1).
Stripe — Stripe Payments Europe, Ltd. (platform) and Stripe Technology Europe, Ltd. (payment services, licensed by the Central Bank of Ireland). Not only a processor: within the scope of its own obligations in payments, fraud prevention and anti-money-laundering Stripe acts as an independent controller.	Card payments, issuing invoices for both card and transfer	E-mail, billing data, amount, payment data (the card number stays with Stripe).
Stripe — for card payments on your Stripe account as your processor under your contract with Stripe, not ours	Card payments of participants and clients	From us only the identifier of the registration or request and the public line item; the payer enters her data directly at Stripe.
Fio banka	Receiving and matching bank transfers	Data about the incoming payment — amount, variable symbol, the sender's account number.
Seznam.cz, a.s. (Email Profi) — a Czech company	The operator's mailboxes and transactional e-mails (payment confirmation, messages about the account); for Booking, codes and messages to clients; for events and deposits, messages to participants and clients; documents that you send by e-mail	Your e-mail and the content of the message; for Booking the client's e-mail, the code, the appointment and the name of the service — not her name, telephone or note; for events and deposits the e-mail, the name of the event or service, the date, a link and, in a payment request, the variable symbol, amount and account; for a document the recipient's e-mail, the text of the message and the PDF.
Brevo (Sendinblue SAS, Paris) — a French company, servers in the EU	Newsletters (only with consent) and the “leave us your e-mail” form on the home page	The e-mail and the content of the message. For the form on the website also the IP address, browser details and the page you submitted from.
Google, Apple	Signing in with the service you chose	That you signed in to Tricho.app, and when. They pass us the account identifier, e-mail and possibly the name and profile photo. For Google additionally, only when you connect the calendar: the server asks for the times of events, your device reads and writes events and tasks directly. The client's name only in the “With the client” mirroring mode, which you turn on.
Server backup storage — Oracle Cloud (Object Storage) in Frankfurt: a separate service outside the server's disk, with the same provider that hosts the sync server. No other recipient.	An encrypted backup of the server in case of a disk or application failure	An encrypted archive of the whole server. The key to it is stored only on the server.
Let's Encrypt (ISRG)	Certificates for the encrypted connection	Domain names and the operator's contact e-mail — none of your data or your clients' data.

We do not load fonts from elsewhere. We serve all fonts from our own addresses; there is no request to a third party. Opening a page therefore does not send your IP address anywhere you would not expect it.

Some of these recipients (Cloudflare, Stripe, Google, Apple and Let's Encrypt) are American companies or process data outside the EU/EEA. The transfer relies primarily on the European Commission's standard contractual clauses under Article 46(2)(c) GDPR; for some recipients the Commission's adequacy decision for the USA (the EU–US Data Privacy Framework, decision of 10 July 2023) applies in addition.

The exception is Cloudflare Email Routing and Workers for bank notifications: the message is readable there while it is processed, so the transfer relies primarily on the EU–US Data Privacy Framework (Cloudflare, Inc. is certified) and in support on the standard contractual clauses. If the Court of Justice of the EU annulled that decision, within 30 days we would move the reception to our own server in the EU or switch the function off.

Two things belong here straight away, so that they are not glossed over: Brevo is not among the American recipients — it is a French company (Sendinblue SAS) and processes e-mails on servers in the EU. And the server on which your data lies is in Germany (Frankfurt nad Mohanem, Německo (Oracle Cloud, region eu-frankfurt-1)); the contents of your vault are not sent to a third country at all, and even if they got there, it would be unreadable encrypted text without a key. What may travel across borders is data about you: the IP address, e-mail, the identifier from the sign-in, billing data.

How long we keep data

The periods are given for each row in the table above. A summary of what people most often get confused about:

The account and its content — until you delete the account.
Invoices — according to the tax rules, at most 10 years, even after the account is deleted. That is required of us by law, not by us.
Server operational logs — days to weeks, depending on how fast the rotating log turns over.
Google Calendar — the access key and the “busy” times until you disconnect or the account is deleted; times only forward, older ones are overwritten.
Cloud backups — 12 months (Pro) or 5 years (Max) back; older ones expire by themselves.
Backups of the whole server — 30 daily, 12 monthly and 2 yearly snapshots. A deleted item can survive in them for up to two years. It is the most uncomfortable sentence on this page and there is no point hiding it.
Bookings from the public page — 7 days after the end, only the appointment and status; the whole one 30 days after the appointment; the client's e-mail encrypted with the server key for no longer than that.
Event registrations — e-mails and links until the end of the event's last day, the rest 30 days longer only as a status record without contact. Bank notifications 30 days after they are resolved, otherwise 90 days; at Cloudflare the sender, address and subject for 31 days.
The record of account deletion — pseudonymous, survives the deletion.
The e-mail from the “Let me know” form — until consent is withdrawn, that is until you unsubscribe with the link in any message.

Your rights

Under the GDPR you have the right of access (Article 15), rectification (16), erasure (17), restriction of processing (18), portability (20) and objection to processing based on legitimate interest (21). You can do almost everything directly in the app: you export the data to a file (portability) and delete the account in Settings. For anything else write to [email protected] — we reply within one month.

We do not engage in automated decision-making or profiling (Article 22). Providing the account data is a contractual requirement — without the e-mail and the identifier from the sign-in we cannot keep an account.

If you are not satisfied with how we handle data, you can lodge a complaint with the Office for Personal Data Protection (Úřad pro ochranu osobních údajů), Pplk. Sochora 27, 170 00 Praha 7, uoou.gov.cz.

What happens on deletion

You confirm deleting the account (Settings → Delete account) by signing in again and typing the confirmation word. The server then removes: your database with the encrypted data, the record of your account, the records of devices, the sign-in tokens, the record of the subscription and of payments, and all cloud backups that have already been made. Local data on the device is wiped too.

Deleting the account does not reach two things: the invoices that we have to retain under the tax rules (at most ten years), and the backups of the whole server, from which your data disappears only with the rotation of snapshots — in two years at the latest. The pseudonymous record that deletion took place also remains. We do not intervene in server backups by hand: they are immutable snapshots and interfering with them would spoil the restore for everyone else.

You do the permanent deletion of a single client directly in her card (“Delete permanently”). 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 three places that even this does not reach the app shows you on the screen before it deletes anything:

Cloud backups that have already been made still contain the client and run for the period of the plan (Pro 12 months, Max 5 years). When you delete the whole account, they 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.
An empty trace remains of her — just the record identifier 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.

Security

Content is encrypted on your device (AES-256-GCM) with a key that never leaves the device; the server stores only the encrypted form and does not have the key. Every encrypted record is moreover bound to its vault and its id, so it cannot be moved elsewhere unnoticed. The connection is always encrypted (HTTPS). Only the operator has access to the server, via a key, and everything done on the server is done by script, not by hand.

Even if data leaked from the server, an attacker would not obtain the readable content of the cards. They would, however, obtain the technical data described above and the data on accounts and payments — those are not encrypted.

Encryption is a measure that Article 32(1)(a) GDPR names expressly. It has a second consequence too: under Article 34(3)(a) the controller need not inform data subjects of a security breach if the data concerned were unintelligible — which is exactly the situation that this arrangement creates for the content of cards. For technical data, however, this does not apply, and the duty to notify the authority does not lapse even for content.

When a security breach occurs

If a security breach occurs on our side, we will let every affected trichologist know without undue delay — as a processor this is our duty to you as the controller (Article 33(2)). We will write what happened, which data it concerns and what we are doing about it. The notification to the Office for Personal Data Protection within 72 hours is then made by you as the controller, from the moment you learned of the breach; how to do it is on the GDPR page. For our own data (account, payments) we notify the Office ourselves.

Encryption reduces the risk considerably, but does not remove it entirely: a breach is also a loss of availability — if the data stayed whole but could not be restored.

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