Security

What is true, and what is not.

Every line here can be checked. The last section lists what we do not have yet — read it first if you are deciding whether we are ready for you.

Last reviewed August 2026

Where it runs

One server, at Hetzner in Falkenstein, Germany. The application, the database and your card photos are all on it. There is no CDN or proxy in front of it, no US region, and no copy of your data in a second region.

klaari.ee is served over HTTPS only, with a one-year strict-transport policy, framing denied and a strict referrer policy. The database and the photo store publish no ports at all, and the network they sit on has no route off the box — the machine exposes the web ports and SSH, nothing else. Administrative access is by key; password and root logins are switched off.

One installation serves every customer, on one hostname. That is worth knowing rather than glossing: it is why the separations below are enforced where they are, in the database and in the storage keys, instead of being inherited from the browser keeping one customer’s site apart from another’s.

Who else sees your data

Three companies are involved in running the product. They are named rather than described, so you can go and read their terms yourself.

HetznerHolds the server and its disks, in Germany. It is the hosting provider and nothing else runs there.

OpenAIReads the card photo, runs the research on a name and a company, and writes a follow-up draft when someone asks for one — so it receives the lead in front of your rep, including the answers recorded at the stand. It does not receive your other leads, your analytics or your team’s details. It processes all of it outside the EU. On their published terms for the interface we use, that data is not used to train their models and is held up to 30 days for abuse monitoring, then deleted. Those are their terms, not something we have negotiated.

BrevoDelivers our email: sign-in links, invitations to join a workspace, and notices about what a workspace has spent. So it receives your team's addresses, the addresses of people you invite, and your workspace name. It is never sent the people in your leads, and we have not verified in which countries it stores mail.

There is no signed data-processing agreement with any of them yet. See the last section, and the privacy page for what is collected and why.

Separation between customers

One installation serves every customer, and the separation is enforced by the database rather than by application code remembering a filter.

Enforced by the databaseEvery table holding your data carries a policy, and the account the application runs as has no permission to bypass it. A test asserts that on every table and every partition each time the suite runs, so a new table cannot be added without it. The database also has an administrative account, as every database does; it is not what the application connects with, and it is reachable only from the server itself.

A missing workspace errorsA query that does not say which workspace it is for fails outright rather than returning an empty list. An empty list is how a missing filter survives unnoticed for a year.

Photos keyed per workspaceEach card photo's storage key begins with your workspace, and a read from outside your own prefix is refused. The photo store is not publicly readable; images are served through the application.

Offline queues stay apartA booth phone holds unsynced captures in a separate store per workspace, and each queued lead names its own, so a tab left open after somebody switched workspaces cannot sync into the wrong one.

Signing in

There are no passwords, anywhere. Sign-in is a one-time link or a six-digit code sent to your email address; both expire after fifteen minutes, and five wrong codes end that attempt. Links and codes are stored only as hashes, so a stolen copy of the database contains no working way in. The session is a single cookie, unreadable to scripts and tied to the exact host that set it.

Sign-in with Google or Microsoft is built but switched on for nobody. Turning it on is a change to the whole service rather than a setting on your workspace, so tell us if you need it. There is no SAML, no SCIM, and no second factor on a customer account — today your email account’s security is your workspace’s security.

Keys and signing secrets

API keys read onlyA key can read leads and analytics and can do nothing else — every write stays behind a signed-in session, because a long-lived key ends up in a scheduled job's environment. Keys are shown once, stored as hashes, and identified afterwards by a short fragment.

Webhook secrets sealedA signing secret created or rotated today is stored encrypted with AES-256-GCM under a key kept outside the database. Secrets created before that change are still stored unencrypted — rotating one replaces it with an encrypted copy, and a sweep to do that for everyone has not run yet.

CRM tokens sealedA HubSpot or Pipedrive credential cannot be stored unencrypted at all: the database rejects the row rather than trusting the code that wrote it.

Deliveries are signedEvery delivery carries an id, a timestamp and an HMAC-SHA256 signature over the exact bytes sent, with the timestamp inside the signed string — so a captured request cannot be replayed under a fresh one. The scheme is documented for whoever builds your receiver.

What we can see

Our own back office runs on an account with permission on the bookkeeping columns only — how many leads, when, what state — across every workspace. Names, emails, phone numbers, notes and photos are refused to it by the database rather than hidden by a screen.

There is one route to lead content and it is audited. It requires a typed reason, and it writes a record naming the staff member, the reason and your workspace in the same breath as the read. There is no way to get the content without leaving the record.

Two things that route does not cover, because a page claiming staff cannot see anything would be easy to disprove. Workspace metadata — how many leads, what you spent, your event names — is readable by our staff without a reason and without a record. So is the directory of account holders: we can search registered email addresses across every workspace, which is how support finds the right one when somebody writes in. Neither reaches lead content.

That record exists but you cannot see it yet — there is no screen and no export. Ask and we will send you yours.

Deleting a lead, and what that means today

Deleting a lead removes it from your lists, your search, your exports and the API. It does not erase it. The record is marked deleted and stays in the database, and the card photo stays in storage; nothing in the product removes either, and no scheduled purge runs.

Two copies also outlive it, and both matter for an erasure request. If the lead was ever sent to a webhook, the delivery log keeps the exact body that was posted, and that body is still readable from the delivery screen. And anything already sent to your CRM is in your CRM — deleting here recalls nothing. Treat deletion today as withdrawal from use rather than erasure.

If a record and its photo need to be genuinely destroyed, write to info@klaari.ee and say so. It is a manual job, and a person does it.

Getting data out is not a request: every lead comes out as a spreadsheet with the columns you choose, or as JSON through a read-only key.

What each capture records

A lead holds what was on the card, what the research pass could support with pages it actually read, the answers your staff recorded, and — where your team chose one — the follow-up basis together with the wording that was in force when it was set. Superseded wordings are kept rather than overwritten, so a lead captured two seasons ago can still be read against the notice of its own time instead of today’s.

What that record is not: it is not evidence the person was shown the wording, and nothing here captures agreement. It tells you which notice was current, and that is a genuinely useful thing to be able to answer later — but a stronger claim would be one the software cannot back.

You are the controller of that data. Klaari records the choice; it does not make it, does not default one, and does not advise on which is right.

Not in place yet

The list a security review asks for, so you do not have to ask. It is longer than these pages usually are, and that is the point: reading it is the fastest way to find out whether we are ready for you.

No external penetration test and no third-party security review. Neither has been carried out.
No data-processing agreement you can sign, and no subprocessor annex. OpenAI's addendum, which would put standard contractual clauses behind the transfer above, is not executed.
A deleted lead is hidden rather than erased, and a copy of it survives in the webhook delivery log.
Off-site backups are not running. Until they are, a lost server means lost data, and no restore has been rehearsed.
The server's disks are not encrypted at rest. Physical security of the datacentre is the hosting provider's.
No retention or deletion schedule enforced by the system. Data stays until somebody deletes it, and deletion works as described above.
Some webhook signing secrets predate encryption at rest and are still stored unencrypted. Rotating a secret fixes that one; a sweep for everybody has not run.
Single sign-on is switched on for nobody, there is no SAML and no SCIM, and customer accounts have no second factor.
No audit trail you can see or export, although it is being recorded.
No self-service deletion of a workspace, and no one-click export of everything at once.
One server: no redundancy, no failover, no point-in-time recovery, and a deploy briefly restarts the application. No uptime monitoring and no service-level agreement.
No bug-bounty programme and no safe-harbour policy.

If one of these is what stands between you and using Klaari, say which one. That is the most useful thing you can tell us, and it moves it up the list.

Reporting something

Found a vulnerability? Write to info@klaari.ee with what you found and how to reproduce it. A person reads that address. There is no bug-bounty programme and no safe-harbour policy, so please tell us before testing anything disruptive.