Data
HR software holds the most sensitive data a company has: what people earn, their national identity numbers, their bank details, and where they were at nine in the morning. Here is precisely how that is protected, in terms you can verify rather than adjectives you cannot.
Isolation is enforced by row-level security in the database, not by what a screen chooses to display. Every query, from every part of the application, is filtered before it returns a row. Tested by querying as an employee of one company across thirteen tables — employees, payslips, documents, audit logs and the rest — the number of rows returned belonging to any other company is zero.
Salaries, payslips and salary history are visible to administrators, to the employee themselves, and to a manager only for their own direct reports. This is enforced in the same layer as tenant separation, so it holds no matter which screen or API the request came through.
National identifiers and bank details are held in a separate table with its own policy: administrators and the employee, and nobody else. Managers are deliberately excluded — running a team is not a reason to hold someone’s national identity number.
Identity and account numbers show as their last four digits and are revealed by a deliberate click. Each reveal is written to the audit log, because reading a payroll screen is routine and uncovering a colleague’s identity number is not.
Creates, updates and deletes across people, payroll, leave, documents and settings are captured at the database level with the previous and new values. A change made by an import or a script is logged identically to one made by hand, because the capture is below the application rather than inside it.
Changing someone’s role updates their permissions and their session token in the same operation. A role that is right in the database and stale in the token is a whole category of quiet security bug, and it is closed by construction here.
Managed PostgreSQL in an EU region, encrypted in transit and at rest, with automated backups. Named sub-processors and their regions are listed in the data processing agreement we sign with each customer — we would rather put them in a contract than on a marketing page where they can quietly go out of date.
Door terminals often only speak plain HTTP and frequently cannot attach an authorisation header. Attendance events carry names and movement times, so we do not ask you to put them on the open internet: a small bridge runs on your own network, attaches the credential, forwards over HTTPS, and queues locally through an outage. It discards the face image, because attendance does not need photographs of your staff.
We do not have a certification badge to show you yet. Plenty of vendors put a logo on a page long before the audit is finished, and you have no way to tell which is which — so instead, everything above is stated specifically enough that you or your security reviewer can test it during a trial.
We are happy to complete a security questionnaire, walk your reviewer through the access model, and put commitments in writing.
Ask us to prove one of these claims. That is what they are for.
We would rather answer hard questions early than discover them at contract stage.