Clocknet runs on a managed virtual private server with a PostgreSQL database. Cloudflare sits in front of it and handles DNS and incoming traffic. [TO CONFIRM: the hosting provider and the country where the server is.]
Face photos are stored in Cloudflare R2 object storage. Other uploads, such as profile photos and time-off attachments, are stored on the server's own disk.
All workspaces share one database. Every query for workspace data is limited to the workspace of the person making it, so one customer cannot read another customer's data. Inside a workspace, access can be narrowed further to subsidiaries and teams. [TO CONFIRM: a separate database for each customer is planned. Update this paragraph if it is live when the page is published.]
Backups: the plan is an encrypted copy of the database and uploaded files every 6 hours, kept off the server in a separate storage bucket for 35 days. [TO CONFIRM: that backups are running in production, and their real frequency and retention. They are not installed yet and are a launch blocker.]
Face photos and the AWS Rekognition face collections are deliberately left out of backups, so that deleting them is final.
Traffic between your browser or the app and Clocknet is encrypted with HTTPS. The website tells browsers to connect over HTTPS only (HSTS). [TO CONFIRM: the minimum TLS version set on Cloudflare, for example TLS 1.2.]
Some sensitive values are encrypted a second time inside the database:
- two-factor authentication secrets and recovery codes
- single sign-on client secrets and identity provider certificates
- the identifiers that link a person to their face template
Passwords are hashed with bcrypt and are never stored in readable form. Sign-in tokens and SCIM provisioning tokens are stored only as hashes.
Backups are encrypted on the server before they are copied off it, and the key that decrypts them is not kept on the server. [TO CONFIRM: depends on backups running in production.]
[TO CONFIRM: whether the database disk and file storage are encrypted at rest, and how. Do not name an algorithm such as AES-256 until this is checked.]
In the mobile app, your sign-in token is kept in the phone's secure storage (the Keychain on iOS, the Keystore on Android). Clock-ins recorded offline wait in the app's private storage until they sync. Signing out deletes the app's local data, any queued photos and the stored token. The app does not add its own encryption to its local database.
Each person in a workspace has a role, and the role decides what they can see and change. Access can also be limited to some subsidiaries or teams, so a manager sees only the people they manage.
Workspace administrators can turn on:
- two-factor authentication with an authenticator app, and passkeys
- a rule that every member must use two-factor authentication, with a grace period
- single sign-on with SAML or OpenID Connect, and user provisioning with SCIM
- an IP allowlist, a limit on sessions per person, and sign-out after a period of inactivity
Some of these depend on the plan.
We limit how often someone can try to sign in with one email address or from one IP address, and how many API requests one user can make. A sign-in token for the app expires after 30 days and is replaced each time the app refreshes it. Signing out, resetting a password, or a forced sign-out by an administrator revokes it.
A log records changes made in the workspace, such as role changes and timesheet edits. It is kept for 2 years.
Clocknet staff use a separate operator console with their own accounts. When support needs to look inside a workspace, the operator must give a reason. The session ends after 60 minutes, blocks most changes, shows a banner, and is recorded in an audit log.
Production secrets, such as API keys, are kept in our hosting provider's secret store and never in the source code.
Changes to Clocknet go through pull requests. Git hooks scan each commit for secrets and run static analysis before code is pushed. [TO CONFIRM: how to describe secret scanning, code review and automated test runs, which do not cover every change today.]
Dependabot watches our dependencies and proposes updates.
The website and admin pages send security headers that stop other sites from embedding them in a frame and stop browsers from guessing file types.
We plan to have an independent penetration test done. [TO CONFIRM: whether one has been done, by whom and when.]
Face verification is optional and stays off unless the workspace turns it on. Each member must give explicit consent before setting it up.
- Face matching uses AWS Rekognition in the eu-west-1 region (Ireland). Each workspace has its own face collection, so faces are never compared across workspaces.
- The photo used to set up face verification is deleted once the face template is made, unless the workspace sets a period for keeping photos. Stored photos are private and can only be opened through links that expire after 10 minutes.
- When a member withdraws consent or deletes their account, their face template is deleted from AWS Rekognition.
- Our development rules forbid writing face photos, face templates, exact coordinates or sign-in tokens to logs. Crash reports are set up so that names, email addresses and IP addresses are not attached.
The Privacy Notice explains face verification in more detail.
- Location sharing during a shift stays off until each member turns it on, and location is recorded only while they are clocked in.
- Location records are deleted after the workspace's retention period, 90 days by default, and within 24 hours if the member turns sharing off.
- Members can download a copy of their data and delete their own account themselves.
The Privacy Notice and the GDPR page explain how we handle personal data.
Errors in the app and on the server are reported to Sentry, so we see problems quickly. [TO CONFIRM: which alerts are set up in production, for example on error rates and backup checks.]
If a security incident affects your data, we will tell the affected customers without undue delay [TO CONFIRM: a fixed deadline, for example within 48 hours of becoming aware of it]. We will describe what happened, which data was affected, and what we are doing about it, and add information as we learn it.
[TO CONFIRM: the incident response plan behind this commitment, which has not been written yet.]
If you think you have found a security vulnerability in Clocknet, please email [TO CONFIRM: security contact email].
Please include:
- a description of the issue and where it is
- the steps to reproduce it
- what an attacker could do with it
We will confirm that we received your report [TO CONFIRM: response target, for example within 3 working days] and keep you informed while we fix it.
Please give us reasonable time to fix the issue before you make it public. Do not access or change other people's data, and do not disrupt the service. If you follow these rules and act in good faith, we will not take legal action against you for your research. [TO CONFIRM: the safe harbour wording, reviewed by legal.]
We do not run a paid bug bounty program. [TO CONFIRM: whether to offer one.]
Our GDPR page explains how Clocknet processes personal data for customers under the GDPR, and describes our data processing agreement.
Clocknet does not hold a security certification such as SOC 2 or ISO 27001.
[TO CONFIRM: Morocco. The status of our declarations to the CNDP under Law 09-08.]
If you need more detail for a security review or questionnaire, contact us. [TO CONFIRM: the contact for security questionnaires.]