Security

You are being asked to put every rate you pay and every margin you make into somebody else's system. Here is what actually protects it — and what does not, yet.

Last updated: 8 September 2026 Governed by South African law

Getting in

PINs and passwords are stored as Argon2 hashes, never as text and never reversibly. We cannot read yours, and neither could anyone who took a copy of the database. A forgotten PIN is reset by your own office; it is never retrieved.
The sign-in screen does not publish your staff roster. It used to list every site manager and driver by name so a man in gloves could tap his own. At a public address that is a list of valid usernames handed to anyone, and it is a disclosure of employees' personal information on top. Names are now typed and resolved on the server, and a name that matches nobody is answered exactly like a wrong PIN — same message, same status, same delay — so the page cannot be used to find out who works for you.
Sign-in attempts are rate-limited, so a four-digit PIN cannot be worked through by a script.
Sessions expire and are cleaned up. The session cookie is HTTP-only, so no script on the page can read it.

What each person can see

The app is three separate shells, each with its own guard, not one app with buttons hidden. A site manager's phone cannot reach an office screen by typing its address, because the office layout refuses him at the server before a page is built.

Site managers see their own sites' capture screens, and no money that is not theirs to see.
Drivers see their advances and their fill-ups.
The office sees review, invoices and master data.
Reports across every site are the owner's.

Privilege changes are checked in both directions. An administrator cannot promote himself to owner, and cannot remove the last owner either — the first would let one person take the business's numbers, the second would lock the business out of them. The system refuses both and says so; a greyed-out checkbox is a convenience, never the control.

In transit and at rest

Everything travels over TLS. There is no unencrypted route into the application.
Sensitive fields are encrypted at rest with a key held in the deployment environment, not in the code and not in the repository.
Photographs of delivery notes and fuel slips are held in private object storage, not on a public URL that can be guessed.
We never see or store a card number. Subscriptions are invoiced and paid by transfer.
Every value arriving from a phone or a browser is validated against a schema before it reaches the database — which is how a malformed capture becomes a clear rejection instead of a corrupted row.

The ledger cannot be quietly edited

Nothing in the cost ledger is ever updated or deleted. A correction posts an equal and opposite entry linked to the original, and an entry can be reversed once and only once. This is an accounting decision first, but it is a security property too: there is no code path that can change what a site cost last March without leaving the original and the correction both visible, side by side, with who did it and when.

It is also why an erasure request cannot simply remove a ledger row — see the retention section of the privacy policy, which says so rather than promising something the system will not do.

Data on a site phone

Site phones are personal handsets, often shared, and they go home at night. So:

Captures held on the phone are the ones not yet sent, and they are deleted from the device as soon as the server accepts them. It is a queue, not a copy of your business.
The offline reference data cached on a phone — sites, products, open orders — is stamped with the user it was fetched for. If a different person signs in on that handset, the cache is discarded rather than adopted, so one man never sees the list that belonged to another.
Signing out clears the session; the next person has to enter their own PIN.

Backups and recovery

The database is hosted on Railway and backed up by the platform. Available on request

You can also ask for an export of your own data at any time, which is the backup that does not depend on us at all.

What we do not have yet

Saying this out loud is the point of the page. Tenvar is a young product run by a small team, and the following are honest gaps rather than things we are being coy about:

No ISO 27001 or SOC 2 certification. We are not going to imply one with a badge.
No independent penetration test yet. Available on request
No two-factor authentication on office accounts yet. Office sign-in is email and password; site sign-in is a PIN, chosen because a man in a trench with gloves on cannot use anything else. Two-factor for office accounts is on the list.
No customer-managed encryption keys and no single sign-on. If you need either, tell us — it would be built for a real customer, not for a page.

Reporting something

If you think you have found a vulnerability, email sales@tenvar.co.za with enough detail to reproduce it. We will acknowledge it, keep you updated, and we will not threaten anyone who reports a genuine problem in good faith.

If personal information under our control is ever accessed by an unauthorised person, POPIA requires us to notify the Information Regulator and the people affected as soon as reasonably possible. We will do that, and we will tell you what happened rather than what is comfortable.