Skip to content

Security

How your data is protected

Attendance data decides what people are paid. This page describes what we actually do to protect it — including the things we have not done yet, because a security page that lists only strengths is not a security page.

Last updated: 25 September 2026

One company cannot see another

AMS is multi-tenant: every client shares the same software but not the same data. Each company gets its own subdomain, and every authentication token carries the company it belongs to. Every database query is filtered by that company identifier on the server, on every request, without exception.

Primary keys are UUIDs rather than sequential numbers. Nothing about your size, your headcount or your record count can be inferred from a URL, and no record can be found by guessing an identifier.

Permissions are enforced on the server, always

Every one of the API's endpoints is gated on a specific permission code and a scope — own, team, department or company. The check happens on the server on every request. Hiding a button in the interface is presentation; it is never the control.

A super-admin session and an employee session use different cookies, different paths and a different token type, so an employee token physically cannot reach an administrative endpoint even if it is replayed at one.

Credentials

Passwords are hashed with bcrypt and never stored or logged in any recoverable form. We cannot read a user's password, and neither can their own administrator.

Sessions use short-lived access tokens in httpOnly cookies, refreshed silently, with refresh tokens stored hashed and rotated on use. Because the cookies are httpOnly, a script on the page cannot read them.

Invitation and password-reset links are single-use, expire (72 hours and 60 minutes respectively), and are stored only as hashes. The forgot-password endpoint answers identically whether or not the account exists, so it cannot be used to discover who works somewhere.

Changing, resetting or setting a password invalidates every other session for that user. Login and both password endpoints are rate limited.

Every change is attributable

Manual attendance entries, regularization approvals and automated changes all write to one audit log: who acted, what the record was before, what it became, and the reason given. A reason is mandatory for administrative actions — the system will not save without one.

This matters more than it sounds. When an employee disputes a deduction months later, the record either defends itself or it does not.

Infrastructure

AMS runs on infrastructure we administer ourselves. Application containers bind to localhost only; nothing in the stack is directly reachable from the internet. A single reverse proxy terminates TLS and is the only public entry point. Each tenant subdomain has its own certificate, renewed automatically.

Databases are backed up nightly and kept off the machine. Error monitoring alerts us to unhandled failures, including failures to send email — which are otherwise the kind of thing nobody notices until somebody cannot sign in.

What we have not done yet

We have not had a third-party penetration test. We do not hold SOC 2 or ISO 27001 certification. We do not offer single sign-on, hardware keys or two-factor authentication yet — SSO is on the roadmap and not built.

If your procurement process requires any of these, tell us early. We would rather lose a deal at the start than pass a questionnaire by being vague about what exists.

Reporting a vulnerability

If you find a security problem, write to support@versnq.in with enough detail to reproduce it. We will acknowledge within two working days and keep you informed until it is fixed.

Please do not test against a live client tenant, and please do not access data that is not yours. Report it and we will reproduce it ourselves. We will not pursue anyone who reports a genuine issue in good faith and gives us a reasonable chance to fix it.