Security

Last updated 13 September 2026

Payroll is the most sensitive system most companies run — every salary, every bank account, in one place. This page describes what protects it, and is equally clear about what we have not built yet.

Access

  • Passwords are hashed with Argon2id, a memory-hard algorithm designed to resist offline cracking. We cannot read your password, and neither can anyone who obtains the database.
  • Role-based access. Accounts are admin, HR, manager or employee, and the data each can reach differs. An employee signing in to the self-service portal can see their own payslips and leave — not their colleagues'.
  • Every organisation's data is scoped to that organisation at the query level, so one customer's records cannot be returned to another.
  • Authentication and session handling are provided by Clerk rather than rolled ourselves.

The audit trail

Significant actions — pay changes, payroll approvals, payments — are written to an append-only audit log recording the actor, their email, the IP address, the time, and the before and after state.

Each entry stores a hash of its own contents together with the hash of the entry before it, forming a chain back to a fixed genesis value. An altered or deleted entry breaks the chain and can be detected. This makes the log tamper-evident: it does not prevent a change, but it makes one impossible to hide.

That matters for payroll specifically. The common fraud is not an outsider breaking in — it is an insider adjusting a figure and removing the trace.

In transit and at rest

  • All traffic is served over HTTPS. The application, the API and the portal share one origin, so no payroll data crosses between hosts in the browser.
  • The admin and employee portal is excluded from search engines by both a robots meta tag and an X-Robots-Tag header, so nothing behind the login is indexed.
  • Payment processing runs through Safaricom's M-Pesa. We never see or store card details, and we do not handle cards at all.
  • Callbacks from M-Pesa are checked against an IP allowlist before being accepted, so a forged payment confirmation is rejected.

What we have not built yet

A security page that lists only strengths is not worth reading. As of the date above, the following are honestly not in place:

  • No third-party penetration test or independent security audit has been carried out.
  • We hold no SOC 2, ISO 27001 or equivalent certification.
  • Two-factor authentication is not yet available on accounts.
  • No fixed retention schedule: nothing is deleted on a timer while an account is open. Account deletion itself is self-serve, with a 30-day grace period.
  • We do not currently publish a formal uptime SLA or status page.

If any of these is a requirement for your organisation, tell us before you commit. We would rather lose the deal than have you discover the gap after moving your payroll across.

Reporting a vulnerability

If you believe you have found a security issue, email info@mavunohr.co.ke with enough detail to reproduce it. Please give us a reasonable opportunity to fix the issue before disclosing it publicly. We will not pursue action against anyone who reports a genuine vulnerability in good faith and does not access or alter other people's data in the process.

For how the data itself is handled, see our Privacy Policy.