Security and data handling
How this actually works, in plain terms.
No photographs are stored. Anywhere.
Face recognition runs in the browser on the device, not on our servers. The camera frame is turned into a list of 128 numbers — a mathematical description of a face — and the image itself is discarded immediately. Only those numbers are sent to us.
That vector is one-way. It cannot be turned back into a photograph, and it is not a fingerprint of anything except a face as seen by one particular model. If our database were stolen tomorrow, nobody would obtain a picture of your staff from it.
Each customer has a separate database
Your workspace is not a row in a shared table with a customer id on it. It is its own SQLite database file, opened only for requests that have already been proven to belong to you.
This is a deliberate choice. The common way tenants leak into each other is a query that forgets its filter, and no amount of care fully eliminates that risk. Here there is no query that could return another company's rows, because another company's rows are not in the file. It is a structural guarantee rather than a promise to be careful.
Consent is recorded, and can be withdrawn
Under South Africa's POPIA, biometric data is special personal information and needs a lawful basis and explicit consent. The GDPR treats it the same way. Klock supports that rather than assuming it:
- No template can be stored for a person until consent is recorded against their name.
- No face is matched at the kiosk without a live, unrevoked consent.
- An administrator can erase a person's templates at any time, in one click.
- Erasing a face keeps their punch history, because that is a payroll record you are required to keep.
Signing in with your own identity provider
You can create a workspace and sign in with Microsoft Entra, Google Workspace, Okta or any OIDC provider, instead of a Klock password. The flow uses the authorization code grant with PKCE; we verify the token's signature, issuer, audience and a single-use nonce.
One rule worth stating because it protects you: an identity provider can only take over an existing Klock account if it explicitly confirms that the email address belongs to the person signing in. Providers that stay silent on that can create new workspaces but cannot walk into one that already exists — that account keeps its password.
Who can do what
Rights are granted as named capabilities rather than an "is admin" flag, so a kiosk token can record punches and nothing else. Reading reports, enrolling a face, erasing biometrics and changing payroll rules are all separate permissions.
| Credential | Can do |
|---|---|
| Kiosk device token | Record a punch. Cannot read a timesheet, list staff, or enrol anyone. |
| Workspace owner | Everything within their own workspace, and nothing outside it. |
| Single sign-on user | Whatever their group membership grants, checked on every request. |
Audit trail
Every enrolment, erasure, manual punch correction, sign-in and settings change is recorded with who did it and when. Punches record their method, so a PIN entry or a manual correction is never indistinguishable from a face match on a payroll report.
In transit and at rest
- All traffic is over HTTPS.
- Sessions are server-side; the browser holds only an opaque, httpOnly cookie.
- Passwords and kiosk PINs are stored as scrypt hashes with per-account salts, never in plain text or reversible form.
- Data is hosted in Microsoft Azure, in Western Europe, on encrypted storage.
AI assistance, and exactly what it sends
Klock can use Anthropic's Claude to summarise a period before you export it, to turn a question into a report query, and to suggest Sage earning codes from a sample you paste. This is the one feature that sends your data to a third party, so it is worth being precise about it.
- Off until you turn it on. Per workspace, by an owner. Nothing is sent before that.
- Face templates are never sent. Not pseudonymised, not encrypted — never sent. There is no code path in the AI feature that can read them.
- Employee codes, not names, by default. The text that leaves our servers names nobody; Klock puts the names back before you read it. You can turn this off if you prefer.
- What is sent: period totals, per-employee hour counts, exception counts, and any sample you paste yourself.
- The model never produces a number. It reads figures Klock has already calculated, or it writes a query that Klock runs. Hours are arithmetic, and arithmetic is not a language model's job.
- Every call is in your audit log — who asked, when, and for which period.
- Metered against a cap you set. Every call records its token cost, and Klock stops when the monthly allowance is used up rather than spending on.
Under POPIA this is a processing operation you are responsible for disclosing to your staff. If you would rather not send anything at all, leave it switched off — every other part of Klock works exactly the same.
What we deliberately do not do
- We do not store, transmit or process photographs of your staff.
- We do not use your data to train anything.
- We do not sell or share personal information with third parties for their own purposes.
- We do not run behavioural advertising trackers on this site.
Being straight about the current limits
Trust is easier to give when someone tells you what is not in place yet. As of today:
- Face templates are stored unencrypted at the column level, protected by the encryption of the underlying storage rather than a separate application key.
- We hold no formal certification such as ISO 27001 or SOC 2.
- Backups are storage-level snapshots; we do not yet offer customer-triggered point-in-time restore.
If any of these are blockers for you, say so — for larger deployments we can discuss private tenancy or self-hosting, where the data never leaves your own infrastructure.
Reporting a vulnerability
Email us with details and we will acknowledge within two business days. We will not pursue legal action against anyone who reports a genuine issue in good faith and gives us a reasonable chance to fix it before disclosure.