"Your data is encrypted" is the easiest sentence in software to write and one of the hardest to check. It can mean a padlock in the browser and nothing else. This post is the longer answer for owners, and for the IT person or accountant who asks them: what F9.contact encrypts, how, with which keys, what we deliberately leave unencrypted, and what happens to the keys when a client or a business leaves.
Three layers, three different jobs
Encryption in F9 works on three layers, and they protect against different things.
In transit. Every connection runs over TLS: the app, your booking page and the client portal. This stops anyone between your device (computer, tablet or phone) and our servers from reading or changing what is sent. It is the padlock, and it is table stakes.
In the database, field by field. This is the layer that matters most for personal data. Before a client's name, phone number or allergy note is written to the database, the application encrypts it. The database never receives the readable text, only ciphertext. A copy of the database (a stolen backup file, a leaked export, someone reading tables they should not) shows scrambled values in place of names, notes and phone numbers. Underneath this, the database also encrypts its own table files, so a copied table file cannot be read on its own.
Access in the app. Once data is decrypted for someone using F9, roles and permissions decide what they see. Encryption does not replace that: a receptionist who is allowed to see a client's phone number sees it in plain text, because that is the point of the app. The roles you set decide who is allowed to see what.
The rest of this post is about the middle layer.
The cipher
Encrypted fields use AES-256-GCM, the authenticated mode of the AES standard with a 256-bit key. Two properties matter in practice:
- Every write uses a fresh random 96-bit initialisation vector, so the same phone number saved twice produces two different ciphertexts. You cannot spot repeated values by comparing scrambled data.
- GCM carries an authentication tag. If a stored value is altered, even by one bit, decryption fails instead of returning tampered text.
One key per record, a key for your salon above it
F9 uses what is called envelope encryption: data is encrypted with one key, and that key is encrypted ("wrapped") with another.
Every record has its own data key. Each client card, booking, consent, staff profile and treatment log gets its own random 256-bit key the moment it is created. That key encrypts that record's sensitive fields and nothing else.
Your salon has a key of its own. The data keys for everything your business holds (client cards, bookings, consents, intake answers, treatment records, staff, your fiscal certificate) are wrapped by a key that belongs to your business alone. It is a randomly generated key, not one calculated from your account details. That choice is deliberate: a key that can be recalculated can never truly be destroyed, and destroying it is how erasure works (more on that below).
Your salon's key is locked too. Your salon's key is itself wrapped by a master key, which is kept separately from the data it protects. Someone holding the database alone holds locked keys to locked data.
A client's own account is a little different. A client can book at more than one salon on F9 with one sign-in, so their account (name, email, phone, profile photo reference) is not owned by any single business. Its data key is wrapped by a separate master key for client accounts, not by your salon's key. What your salon records about that client (your notes, allergies, treatment history, consents) stays under your key.
Master keys can be rotated. Rotating a master key re-wraps the keys under it without decrypting and rewriting every record.
What is encrypted
On the salon side, under your business's key:
- Client card: your notes and allergies; for hair salons, current hair colour and preferred product brand.
- Bookings: booking notes.
- Treatment records: the four notes on a chemical service (scalp condition, adverse reactions, result, next-visit recommendation), patch-test reaction notes, staff-only private notes, after-visit observations, and photo captions.
- Consents and intake forms: the client's answers, the name they typed to sign, and the sealed record of what they agreed to.
- Staff: first and last name, email, phone and OIB of every worker and staff account.
- Fiscal certificate: the certificate and its password, unlocked only for the moment it takes to sign a receipt.
On the client's own account, under the client-account key: first and last name, email, phone, the reference to their profile photo, and the secrets behind their sign-in methods.
On your business account: the contact person's name, phone and email, and the credentials of the payment terminal and accounting connections you link.
How we find what we cannot read
Encrypted data cannot be searched directly, yet a client has to be able to sign in with their email, and your front desk has to be able to type "Mar" and find Marija.
For email, F9 stores a keyed HMAC-SHA256 fingerprint of the lower-cased address next to the encrypted one. A sign-in computes the same fingerprint and looks it up. The fingerprint cannot be turned back into the address, and it is keyed with a secret kept separately from the data, so it cannot be checked against a list of guessed addresses without that secret.
For names, F9 stores keyed fingerprints of the beginning of each first and last name, from two to seven letters, after removing diacritics (so "Ričardson" and "Richardson" match). A search looks up the fingerprint of what you typed, then narrows the results by decrypting the candidates and comparing the full text.
The trade-off is honest and worth naming: the same email always produces the same fingerprint (that is what makes sign-in work), so the database can tell that two rows share an address, without knowing what the address is.
What is not encrypted, and why
Some data is not field-encrypted, by design:
- Photos and files. Before-and-after photos, profile pictures, sealed consent PDFs and data exports live in private storage in the EU. We do not encrypt the files themselves. The storage is private, and every file is served only through a signed link that expires: an hour for profile pictures, a day for treatment photos and exports. Uploaded photos are re-encoded on our servers, which also strips the hidden metadata a camera embeds, such as location and device.
- Birth dates. Kept readable in a table of their own so the app can find upcoming birthdays. They are deleted, not just hidden, when a client's account is erased.
- The public side of your team. A worker's display name, bio and photo exist to be shown on your public booking page, so they are not encrypted. They are deleted outright when your business closes.
- Operational records. Appointment times, services, prices, stock and receipts are not personal details in themselves, and receipts in particular must stay readable under Croatian fiscal law.
- Colour formulas. The recipe (mix, developer, levels, tone) is trade knowledge, not personal data. The result notes around it are encrypted.
- Sign-in metadata. The browser and network address on a client's remembered devices and sessions are kept readable for security, and deleted when the account is erased.
What happens when someone leaves
Because every record's key hangs from a key above it, erasure is done by destroying keys. A destroyed key is removed from the database, not just flagged, and anything wrapped by it cannot be decrypted again by anyone, including us. Backups taken before that day still hold the old key until they expire on the backup schedule.
When a client is forgotten. After the 30-day cooling-off period, every data key of the client's own account is destroyed, so their name, email, phone and sign-in details can no longer be read. Their sign-in tokens, device registrations, one-time links and birth date are deleted. Your salon's own records about that client follow your retention policy, which is how GDPR Article 17(3) lets you keep what you are obliged to keep.
When a business closes. F9 destroys your salon's key. In one step, every data key wrapped by it becomes unreadable: client cards, bookings, consents, treatment records and staff, including any kind of record added to F9 in the future, because it is wrapped by the same key. The contact person's details are destroyed with their own key, the email fingerprints of your staff are cleared, and your team's public profiles are deleted outright. Records Croatian fiscal law requires to be kept stay, without readable personal details.
What encryption does not protect against
We would rather say this plainly than have you find it out. Field encryption protects data at rest: in the database, in database copies, against someone reading tables directly. It does not protect against someone who takes over a user account in your salon, and it does not protect against someone who takes over our application servers, because the app has to be able to read the data to show it to you. Those risks are handled by other means: roles and an audit log on your side, and access control on our infrastructure on ours.
If you want to go deeper, the Trust & security page summarises where data is hosted and how GDPR rights work in F9, and our practical GDPR guide covers what the regulation asks of you as the controller.