Security

Your staff's hours, locations and leave are personal data. This is how KiteClock looks after them.

Last updated 24 October 2026.

Where your data is

KiteClock's database, files and sign-in run on Supabase, in Amazon Web Services' EU (Ireland) region. Data is encrypted in transit, and every connection to the apps and the website uses HTTPS.

Each business sees only its own data

• Row-level security is switched on for every table, so the database itself refuses access to another business's data, or to another person's data where staff shouldn't see it.
• Automated tests check that no business can reach another's records and no staff member can reach a colleague's.
• A person's business and role come from their sign-in, not from anything the app sends.

The server decides

Clock-ins, edits and approvals all go through server functions that check the rules. The time comes from KiteClock's server, location is checked against the fence on the server, and totals are worked out there, so a changed phone or a tampered request can't change anyone's hours.

• Clocking is limited to 20 requests a minute per person, and sign-in attempts are rate-limited.
• QR codes change every 30 seconds and NFC taps become one-use passes that last 5 minutes.
• Kiosk PINs are stored scrambled (bcrypt) and lock after wrong guesses.

Our own team's access

KiteClock staff use a separate HQ portal that needs two-factor sign-in on every action. HQ sees facts about each business (its name, plan and how many people it has), not people's hours or locations. To help with a problem, support can look, read-only, only while your admin has turned on support access for 1, 7 or 30 days, and every look is recorded in your own change history.

Files and records

• Photos, attachments and export files are in private storage, opened with links that expire after 5 minutes.
• Every change to hours, pay or leave records who made it, when, the old and new value, and the reason.
• Payroll export files are deleted after 30 days; clock records are kept for the period you set (2 to 10 years).

How we build

• Every change to the database is a reviewed, tested migration.
• Secrets are kept out of the code, and the code history is scanned for leaked secrets.
• A security review of the product found no critical or high issues; the medium and low findings were fixed.

Report a problem

If you think you've found a security problem, please tell us through the contact form and we'll respond as soon as we can.