Security

A time record is a wage record, so On Post does not let anyone edit one in place — including us. Clock-ins and clock-outs are stored append-only, enforced by the database itself rather than by application code that could be bypassed. There is no screen, no menu item, and no support action that rewrites a clock-in.

When a manager fixes a time — someone forgot to clock in, and said so — the fix is a new row recording who made it, when, and both the previous value and the new one. The original is still there. A business can read that trail for itself in its own audit log; it is not something only we can see.

Every record in the system carries the business it belongs to, and every query runs through a data layer that scopes to the business in the current session. Which business you are in is resolved from your session — never from a web address, a form field, or a header a browser could be made to send.

Underneath that, the database enforces the same boundary again with row-level security, so a mistake in application code is caught a second time rather than becoming a leak. An automated test that seeds two businesses and tries to read each one’s data with the other’s session runs on every single change we make; it has to pass before anything ships.

Businesses under common ownership are a deliberate exception only in what it grants: a switcher and combined totals. It never grants one company’s managers access to another company’s records.

Sessions are a random token in a secure, http-only cookie, stored only as a hash and checked against the database on every request. They are not self-contained tokens carrying claims, which means access can be withdrawn instantly: end someone’s employment, remove a manager, or sign out everywhere, and the very next request is refused. Nothing waits for an expiry.

Passwords and clock-in PINs are stored as argon2id hashes. Two-factor authentication is available to every business on every plan, with recovery codes, and a business can require it of its owners or of everyone. Sign-in, password reset, and PIN entry are all rate-limited.

A shared time clock authenticates as itself — a token issued to that tablet, stored hashed, reporting in on a heartbeat, and revocable from the manager’s settings without touching anyone’s account. No one’s email address and password are ever what makes a tablet a time clock, so a tablet on a wall in a public room is not a way into the business’s records. If it goes missing, you turn off that device.

On Post takes no biometric identifiers and performs no facial recognition. A clock-in photograph is a picture, reviewed by a person at the business if it is reviewed at all. We do not derive face geometry from it, we do not match faces between images, and we do not sell or share these photographs.

Photographs are encrypted at rest and reachable only through links that expire five minutes after they are issued — a copied link is not a permanent door. How long they are kept is the business’s setting, with a default of two years and a floor of ninety days, and expiry means the file is deleted rather than moved somewhere cheaper. The time record itself outlives the photograph, because the record is what pays people.

The records a business creates belong to that business. Time records, the team roster, the schedule, payroll figures and the audit log can be exported to ordinary spreadsheet and CSV files at any time, without asking us and without a support ticket — and an owner can take everything the business holds as one file, a CSV per table in a ZIP with a README, from Settings, ready in minutes and never conditioned on the account balance. Closing an account does not delete its history: wage records have to survive for years under federal recordkeeping rules, so a closed business keeps a readable, read-only account rather than disappearing. Permanent deletion is a separate, deliberate request, and a deleted business is purged thirty days after it.

A business can let a system it runs read its record through the API: who is on post, the locations, the team, the published schedule and time cards. The API is read-only by construction — nothing outside On Post can write a clock-in or change a record. A key is created by an owner or general manager, is shown once and stored only as a hash, is limited to the endpoints it was given, is refused on its next request the moment it is revoked, and is checked against the business’s plan on every call. Keys never return a legal name, a PIN, a date of birth, contact details, pay or photographs. Webhooks are signed with a per-endpoint secret (HMAC-SHA256 over a timestamp and the body), may only point at a public HTTPS address, and are never followed through a redirect. The full mechanics are on the API reference.

We do not store card or bank details, and we never will. When billing opens, payments will be handled by a specialist payment processor that is certified to the card industry’s own standard, and card numbers will be entered into that processor’s form rather than ours — they do not reach our servers at any point. A free trial requires no card.

A security page that lists only strengths is a sales page. These are the honest gaps, and this section will get shorter rather than quieter.

• No SOC 2 report. We have not completed a SOC 2 Type II audit. If your business needs one to sign, tell us — it is a question of timing and cost, not of willingness, and we would rather say so than imply an audit we have not had.
• No third-party penetration test yet, and no bug bounty program. Security work so far is our own: automated tests, a strict content security policy, and the isolation test described above.
• We are not a HIPAA business associate. On Post records hours, not health information. Do not put patient information into notes or documents here.
• No published uptime commitment. We do not offer a contractual service-level agreement at these prices, and we will not print a number we cannot stand behind.

If you believe you have found a vulnerability, email security@getonpost.app with enough detail to reproduce it. We will acknowledge you, keep you updated while we fix it, and we will not pursue anyone who reports a genuine finding in good faith and does not access or alter other people’s data. Do not test against a real business’s account.