Skip to main content

Security

Payroll data is a target: names, addresses, identification numbers and bank details in one place. This page describes what protects it, specifically enough that you could check.

Last checked against the software on 15 September 2026.

A draft, not a legal document

PayRole is pre-release. This page describes honestly what the software does, and you can hold us to that. It has not been drafted or reviewed by a lawyer and is not a contract, a privacy notice under the GDPR or the CCPA, or legal advice. Do not rely on it to meet an obligation of your own.

Keeping companies apart

  • Every company is a separate tenant, and every database query is scoped to one organisation by the data layer rather than by each page remembering to filter.
  • A record belonging to another company reads as not found rather than as forbidden, so no one can learn that a company exists by probing for it.
  • Access inside a company is governed by 10 roles across 49 permissions — a bookkeeper who can see payroll but cannot approve it, a manager who only sees their own team.
  • The few actions that move money or change where it goes require your password again at the moment you take them, so a borrowed open laptop is not enough.

Secrets and sensitive fields

  • Passwords are stored only as salted scrypt hashes with a deliberately slow cost. We cannot read them.
  • Session tokens are random, opaque, and stored only as hashes. A copy of the database does not let anyone sign in.
  • Tax registration numbers — and government identification numbers and bank details, when those exist — are encrypted with AES-256-GCM under a per-record key before they reach the database, using a master key the database does not hold.
  • Full bank account numbers, government identification numbers, tax identifiers and authentication secrets are never written to a log, an error report or an analytics event.

In the browser

  • Session cookies are HTTP-only, SameSite=Lax, Secure in production, and carry the __Host- prefix, which the browser itself enforces.
  • Every form that changes something carries a CSRF token bound to your session.
  • A content security policy restricts what the page may load and where it may send data.

A record of what happened

Every change that matters is written to an append-only audit trail: who, what, when, and from where. The ledger underneath payroll is double-entry, and the requirement that it balances is enforced by the database rather than by the code that writes to it. Neither can be quietly edited after the fact.

What is not true yet

Being specific here matters more than sounding reassuring. PayRole is pre-release. It has not had an external penetration test, it holds no security certification — no SOC 2, no ISO 27001 — and claiming otherwise is exactly the kind of statement this page exists to avoid. Do not put real worker identification numbers or bank details into it today.

Telling us about a problem

If you find a vulnerability, please report it to info@payrole.net rather than test how far it goes, and give us a reasonable chance to fix it before telling anyone else.

We will not pursue anyone who reports a problem in good faith. There is no bounty and no formal disclosure programme — saying otherwise would be inventing a process that does not exist — but a report sent there is read by a person who can act on it.