Security

We hold no certification

PEOPLE and SPEED hold no SOC 2, no ISO 27001 and no other security certification. Nobody has audited this system. If a certification is a procurement requirement for you, we do not meet it today and we would rather you knew now.

What follows is a description of how the system is built. It is checkable — every mechanism below corresponds to code and, in most cases, to a test that fails if the property is removed — and it is not a substitute for an audit.

Tenant isolation

Separation between customers is enforced in the database, not only in application code. Every payroll table carries the company it belongs to. Row-level security checks that company directly and requires an active access statement for the organization named by the current transaction.

The application connects as a role that cannot bypass those policies, and the server refuses to start if the role it is given can — so a misconfigured deployment fails loudly at boot rather than serving every tenant's data to whoever asks.

Privileges are granted per table on purpose. A table added later arrives with no privileges at all, and the migration that creates it has to say explicitly what the application may do with it. That way a new table is not silently writable.

Better Auth owns identities, credentials and HTTP-only sessions. A session selects an organization only from its current memberships. Every company transaction rechecks the live session, selected organization, latest membership and latest company access in PostgreSQL.

Records are append-only

Employment records, facts, compensation and statutory rule data are effective-dated and append-only. A correction is a new row with a later commencement, never an edit over the old one — so the history of what was known, and when, survives.

This is a security property as much as a correctness one. There is no operation that rewrites what a payslip was computed from, which means a dispute about an amount is settled by recomputation rather than by trusting a log.

Statutory rate changes are inserts. A payslip recomputed years later resolves the rates that were in force in its own month, not today's.

Money and determinism

• No floats. Amounts are integer minor units inside the engine and decimal strings on the wire. A float is the wrong type for money in a way that surfaces as a one-sen discrepancy months later.
• No clock. The engine cannot read the time. Reading the system clock is banned and the ban is enforced by a check that fails the build, so the same inputs always produce the same output — a run cannot depend on when it was executed.
• No input, no output. The engine performs no IO and imports no framework. Everything it needs is passed in, which is what makes a payslip recomputable from what was stored.
• Every line carries its derivation. Rate, statute citation, effective date and a verified flag, on each computed line.

Validation happens at the boundary

The API contract is defined once, and the request validation, the OpenAPI document, the generated client and the agent tool list all come from that one definition. There is no second copy of the contract to drift out of step with the first.

Bad input is refused where it is typed rather than where it is used: an unknown fact key, a fact recorded against the wrong subject, an answer a choice does not offer, money sent as a bare number, an item type the country pack rejects. A wrong value accepted into the record blocks a payroll weeks later under a description that sends whoever typed it looking for something unrelated.

This website

Static files. No analytics, no tracking pixels, no third-party scripts, and no cookies set by us. Fonts are self-hosted, so rendering this page makes no request to any other party. There is no form on the site that submits anywhere — the newsletter pill and every call to action open your own mail client.

Security work that is not done

Complete list, as far as we know it:

• No multi-factor authentication. Email/password accounts and sessions exist; a second factor does not.
• Only owner and operator roles exist. Invitations and finer-grained permissions are not implemented.
• No audit log of reads. Writes are recoverable from the append-only record; who looked at what is not recorded.
• No rate limiting anywhere in the API.
• No penetration test has been performed.
• No formal backup or recovery procedure is documented, because nothing is deployed yet.
• No encryption at rest beyond whatever the eventual host provides by default.
• No published vulnerability disclosure policy. Until there is one, mail the address below and we will respond.

Reporting something

If you find a security problem, mail hello@flightworkly.com with "security" in the subject. It reaches the person who wrote the code. We will confirm receipt, tell you what we found and tell you when it is fixed. There is no bounty programme and we will not threaten you.