Security
How we protect employee data
An HRMS holds some of the most sensitive data an organisation has — salaries, addresses, attendance patterns, medical leave. These are the controls that protect it, described plainly enough to be checked.
Tenant isolation
Each customer's data is separated at the data-access layer rather than by a filter that application code has to remember to apply. A database query issued without an authenticated tenant context fails outright instead of returning everything. Cross-tenant reads are refused and reported as not-found, so a probe cannot even confirm that another organisation exists.
Encryption
All traffic is TLS-encrypted in transit. Data is encrypted at rest, including backups. Passwords are hashed with a slow, salted algorithm and are never recoverable — a reset issues a new one rather than revealing the old.
Authentication and sessions
Short-lived access tokens paired with rotating refresh tokens. Reusing a refresh token invalidates the entire family, so a stolen token stops working the moment the legitimate one is used. Account owners control password strength, session lifetime and lockout thresholds.
Access control
Permissions are granular and roles are yours to define. Viewing is separate from managing throughout, and salary visibility is a separate permission from the rest of an employee record. Revoking access takes effect immediately rather than at next sign-in.
Audit logging
Sign-ins, permission changes, record and salary changes, payroll approval, attendance locks, exports and file access are all recorded with actor, timestamp, source address and before/after values. Entries are append-only and cannot be edited or selectively deleted from the product — including by an account owner.
Input handling
Salary formulas are evaluated by a purpose-built expression engine with no access to code execution, host objects or property lookup. Tenant-supplied formulas cannot run arbitrary code on our servers. Uploads are checked against per-category allow-lists, and SVG is always served as a download rather than as same-origin markup.
Operational practice
Development, staging and production are segregated, and production personal data is never copied into development or testing. Access to production is individually authenticated, time-limited and logged. Dependencies are monitored for known vulnerabilities.
Backups and recovery
Databases are backed up daily and retained for 30 days, with restores tested regularly rather than assumed to work. Recovery point objective 24 hours, recovery time objective 8 hours.
Reporting a vulnerability
Write to security@chefotech.com before you start testing, and we will agree a scope with you. We will acknowledge within two business days and keep you updated until it is resolved.
We will not pursue legal action against researchers who stay within an agreed scope, avoid accessing other customers' data, and give us a reasonable chance to fix what they find before disclosing it.
What we do not claim
We do not currently hold ISO 27001 or SOC 2 certification, and this page does not claim otherwise. The controls described above are implemented and can be demonstrated; independent certification is a separate exercise, and a vendor page that implies one it has not completed is worth less than an honest list.
If your procurement process needs a security questionnaire completed or a review of our sub-processors, write to security@chefotech.com.
Related
Try it with your own policies
The trial is a full account, not a sandbox. Configure your real leave rules and see what the engine does with them.