Security
Your competitors are in this database.
That is the honest shape of the problem, and pretending otherwise would be the first thing to distrust. Here is what actually stops one bidder seeing another's work — the mechanism, not the promise.
Isolation is enforced by PostgreSQL, not by our code
Every table carrying tenant data has forced row-level security. The role the application connects as is not a superuser and cannot bypass those policies, so a missing WHERE clause in our code returns nothing rather than everything. That is the difference between a bug and a breach.
And it is proved on every build
For each tenant table there is a test that creates two organisations and asserts that one cannot read, update, insert into or delete the other's rows. A new table without such a test fails the build — the coverage list and the live database schema have to agree.
There is no code that can send your email
Mailbox integration requests compose-and-draft permissions only. Not “we choose not to send” — the send-capable permissions are never requested, and a build-time check across the whole repository fails if a send endpoint or a send scope ever appears in it. A draft lands in your Drafts folder; you press send.
Tokens are encrypted at rest
Mailbox credentials are sealed before they touch the database, with a key the database does not hold. A copy of the data on its own does not open your mailbox.
Nobody at Uhuru can look without your permission
Support access is a record you write, naming one person, with a reason and an expiry, revocable at any moment. There is no path in the code by which we create one for ourselves. Every use is written into your own hash-chained ledger — visible in your activity feed, and carried into any evidence pack you export.
The record is tamper-evident
Ledger entries are append-only at the database level: update and delete are revoked, with triggers behind that. Each entry hashes the one before it, so removing or editing one breaks every link after it — and the verifier that detects this ships inside your evidence pack, with no dependencies and no connection to us.
What we do not claim
Procura holds no ISO 27001 or SOC 2 certification. Saying otherwise on a page like this would be exactly the behaviour it is meant to reassure you about. What we can offer instead is that the mechanisms above are checkable: the evidence pack verifies without us, and the support-access record is yours rather than ours.
A hash chain is tamper-evident, not tamper-proof. It proves that nothing has been altered since it was written, and it does not defend against a wholesale rewrite by someone with full database control — that needs the head hash published somewhere outside this system, which is a v1.1 change and is written down as such rather than glossed over.
Your data, and POPIA
Uhuru AI (Pty) Ltd is the operator; your organisation is the responsible party for the bid data you put in. Personal information — the CVs you upload, the buyer contact people we read off a notice — is covered in the processing notice, including the lawful basis for each, the suppression list, and how to ask for an export or a deletion.