Security & trust
HR data is the most personal data a company holds
Salaries, passports, medical documents, disciplinary cases — HumanR exists to hold exactly the records that must not leak. This page explains how the product protects them, in the same plain language we use everywhere else.
Role- and permission-based access
Access is granted by role and permission down to individual modules and sensitive fields. Payroll figures, HR cases and personal documents stay on a need-to-know basis — a site supervisor and a payroll officer see very different systems.
Sensitive fields masked — and access logged
Salary figures and other sensitive values are masked for anyone without the specific permission to see them, and access to sensitive data is itself recorded. Looking is an event, not a habit.
A full audit trail
Who changed what, and when — recorded across the system, from a corrected attendance punch to an approved salary increment. When an auditor asks, the answer is a report, not a shrug.
Encrypted in transit
All traffic between your browser, your biometric devices' punches and the system travels over encrypted connections.
API tokens that cannot outgrow their issuer
A REST API token is shown once and stored only as a hash, so nobody — us included — can read one back out of the database. It carries only scopes its creator already held, can be pinned to one company with an expiry date, and is logged by its short prefix, never its secret. A leaked token's blast radius is bounded by a person you can name, and revoking it takes one click.
Your data stays yours
Every list in the system exports to a file you own. If you ever leave, you leave with your data — no export fees, no hostage formats.
Demo companies are fiction
The self-serve demo runs on fully seeded, fictional companies. Exploring the demo never touches a real customer's data, and nothing you do in a demo company leaks anywhere.
Where it runs, and what backs it up
The first page of every vendor security questionnaire asks the same handful of things. Rather than make you send the questionnaire to find out, here are the answers.
- Where it runs
- Our cloud runs on AWS in the Asia Pacific (Singapore) region — close enough to the operations we serve that the system feels local. Or it runs on your own servers: the same build, deployed either way, with no cut-down on-premise edition.
- Where your data sits
- For cloud customers, in that same Singapore region — it is not moved around between regions behind your back. On your own servers, it sits wherever those servers are and never leaves them. If your group has a residency rule, one of those two answers satisfies it.
- Encrypted in transit and at rest
- Traffic between your browser, your biometric devices and the system travels over encrypted connections, and the volume the database sits on is encrypted at rest.
- Backed up nightly, off the machine
- The database is dumped nightly to a copy kept off the application server, so losing the server does not mean losing the data. Every release also snapshots the files it replaces — which is what makes a bad deploy a rollback, not an incident.
- Sign-in and sessions
- Passwords are stored hashed, never recoverably — we cannot read yours and neither can anyone who reaches the database. Every account carries a live list of its own sessions with sign-out-everywhere, and employee portal passwords are reset by HR in person rather than by an emailed link, so there is no reset mail to intercept.
Data processing
Procurement asks two questions here, and they have short answers: who is responsible for the data, and what will you sign.
Who is the controller and who is the processor?
You are the controller of your employees' data — you decide what is collected and why. We are the processor: we hold and process it to run the service you bought, on your instructions, and for nothing else. We do not sell data, we do not share it with advertisers, and we do not use your HR records to train models.
Will you sign a data processing agreement?
Yes. We do not publish a DPA as a download because we would rather agree the terms with you than hand you a boilerplate to accept — ask us and we will send one for your legal team to review. If your organisation has its own standard DPA, send that instead; we will read it and tell you plainly which clauses we can meet and which we cannot.
Who inside your company can see our data?
Support access is by request and by exception, not standing. When we do need to look at your instance to solve a problem, the same audit trail that records your users' actions records ours, and access to sensitive fields is itself an event. On a self-hosted install we have no access at all unless you give it to us.
Where does the data go if we run it ourselves?
Nowhere. A self-hosted instance talks to your database, your SMTP server and your biometric devices. It does not call home, and it does not need outbound internet access to work.
Retention & deletion
How long things are kept, and what happens when they stop being needed. Where the product enforces a period automatically, the number below is the one in the code.
Employee records
No automatic expiry. Terminating archives the file rather than erasing it; deletion is an explicit action you take.
Until you delete
Audit trail — changes
What changed is kept indefinitely. An audit trail with a short memory is not an audit trail.
Life of instance
Audit trail — views
Who viewed a sensitive field is higher-volume and lower-value over time, so it is trimmed after a year.
365 days
Sessions
A dead session row lingers so you can still spot a login you did not make, then it is swept away.
30 days
Webhook deliveries
So a consumer that was down can see exactly what it missed rather than discovering the gap later.
30 days
Job applicants
Anonymised after last activity, CV files included. Configurable per install with a 30-day floor; candidates can self-erase.
180 days
Backups
Nightly dump kept off the server; older copies age out, so deletions clear as copies cycle. The term is in your agreement.
—
Leaving
Full export on request, then deletion on your written instruction. No export fee, no hostage format, no notice period.
—
The straight answers section
Security pages love logos. Here is ours, in words: we would rather tell you plainly what we do and don't have than decorate this page with implications.
Are you SOC 2 or ISO 27001 certified?
Not yet. When we complete a certification it will be listed here with the report available on request — until then, we won't imply otherwise with badge-shaped graphics.
Do you support two-factor authentication?
Not yet. Accounts are protected by hashed passwords, a live session list you can sign a device out of remotely, and HR-mediated resets instead of emailed reset links. 2FA is on the roadmap, and this answer changes the day it ships rather than the day we decide to imply it.
Can we run it on our own servers?
Yes — and it is the same build we run in our own cloud, not a reduced on-premise edition kept a version behind. Groups with a hard data-residency rule, or an IT policy that will not put payroll in someone else's cloud, take this route and lose nothing by it.
Running a vendor security assessment?
Send us your questionnaire. We answer every line honestly, including "not yet" where that is the truth, and we answer fast.
Found a vulnerability?
Report it and we will take it seriously — see the disclosure contact below. We commit to acknowledging reports quickly and to not pursuing anyone acting in good faith.
Straight answers, in writing
Ask us anything about how your data is held. We would rather lose a deal on an honest answer than win one on an implied certification.
Hakuna kadi ya mkopo. Hakuna simu ya mauzo. Akaunti halisi ya kuingia, inayotumwa kwa barua pepe.