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, for every query the data layer runs on a business’s behalf, the database enforces the same boundary again with row-level security, so a mistake there is caught a second time rather than becoming a leak. A small number of system paths run before any business is known — signing in, pairing a time clock, nightly housekeeping — and so sit outside that second check; each one names the business explicitly and is covered by the same tests. 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.

On Post runs on Amazon Web Services in the United States. Every connection to it uses TLS 1.2 or 1.3; a plain HTTP request is redirected, and browsers are told to use only HTTPS for two years. The database is encrypted at rest and sits in a private network with no route to it from the internet. Photographs and backups are encrypted at rest too.

The database keeps point-in-time recovery for seven days. Separately, a copy is written every night to a different provider, under a credential the application itself never holds, so a fault in the application cannot read, change or delete the backups. Daily copies are kept for thirty-five days and the three newest monthly copies for longer, and a monthly copy cannot be deleted or overwritten for sixty days, not even with the key that wrote it.

Every week we restore the newest nightly copy into a fresh, temporary database and check every table’s row count, a checksum of the clock-in records, and the number of database migrations applied, against a manifest written when the copy was taken. The targets are a copy no more than twenty-six hours old and a restore finished within thirty minutes.

There is no impersonation feature, and support never sees or sets anyone’s password. Support can correct a team member’s contact details and send a sign-in link to the address on file; both appear in your audit log, so a change of address made by us is never silent.

Our support console requires a password and a code emailed at every sign-in, and signing in to it sends us an alert. It shows a business’s name, plan, locations and time clocks, and its team members’ names, contact details, whether they have an account, and when they last clocked in, which is what it takes to help someone get in. It does not show time records, photographs, schedules or pay.

When support acts on someone’s account (sends a sign-in link, sends a password reset, signs them out), the action appears as On Post support in the audit log of each open business they belong to. Direct access to the database exists only to run the service: it happens from inside the private network, and our cloud account’s audit trail records every session.

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 are stored as argon2id hashes. A clock-in PIN is checked against an argon2id hash too; because managers can look a PIN up for an employee, it is also kept encrypted, under a key held outside the database. 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; on the Free plan they are kept for ninety days. 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. An owner can also request the business’s records as one file, a CSV per table in a ZIP with a README, from Settings. It is usually ready in minutes, can be downloaded for seven days, and is never conditioned on the account balance. It does not include clock-in photographs or uploaded documents, and a business past 500,000 rows or 200 MB is told so rather than given a partial file.

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. A deleted business is kept for thirty days so it can be restored, then purged; the copies of it in our backups age out on the schedule above and are gone within about three months of the purge. Sign-in accounts belong to a person rather than the business, and are deleted separately on request.

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. The database runs as a single instance in one availability zone, so an outage there means downtime while it is restored.
• No single sign-on. Signing in through your own identity provider (SAML or OpenID Connect) is not available yet. Two-factor authentication is available on every plan.
• No web application firewall. Sign-in, password reset, PIN entry and the API are rate-limited in the application itself.
• No standard data processing agreement yet. If your business needs one to sign, tell us.

If you believe you have found a vulnerability, email security@useonpost.com 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.

We keep a written incident-response plan. If your business’s data may have been involved in an incident, we tell you promptly once we discover it, without waiting for the investigation to finish.