The evidence is in your hands, not on our server.
A sealed document verifies in the reader’s own software, with no Vumasign account and no request to us. That is the strongest thing this page has to say, and it is checkable in about thirty seconds.
Application, database, documents and sealing all in Google Cloud’s africa-south1 region. Not a data-residency add-on, not an enterprise tier — the only place this system has ever run.
A PAdES seal with a trusted timestamp, verified in Adobe Reader with no Vumasign account and no request to a Vumasign server. Evidence you hold rather than evidence we hold for you.
Row-level security in the database itself, not a `WHERE` clause a future query could forget. A query that leaks across tenants does not return the wrong rows — it returns none.
Append-only at the database level. There is no code path, and no support procedure, that rewrites an event after it happened.
One region, and it is not a setting.
Application, database, document storage and the sealing service all run inafrica-south1 — Google Cloud’s Johannesburg region. There is no other region to fall back to, no replica elsewhere, and no plan on which residency is an upgrade.
What that removes from a reader’s work is specific: POPIA s72 governs transferring personal information out of the country, and a transfer that does not happen needs no justification, no adequacy finding and no clause in a contract nobody will read.
How we talk about POPIA- Data stored and processed in South Africa, for every account, on every plan
- A written operator agreement (s21) you can attach to your records
- A South African operator with a registered company, named people and a physical address
- Export of every document and audit trail, documented, so you can leave
Four steps, and the first one is the one nobody advertises.
The original’s hash is verified before a single answer is written into it. That is the difference between sealing a document and sealing the document you uploaded.
The signature covers the fully assembled file — flattened answers and certificate pages both — because signing happens last. A signature applied before the certificate was appended would either break on appending it or, worse, stay valid while covering only part of what the reader sees.
- Verify
The original’s SHA-256 is checked before anything is written to it. A mismatch aborts the job rather than sealing something else.
- Flatten
Every answer is drawn into the page as part of the document, not as an annotation a viewer can hide or a later tool can strip.
- Certify
The Certificate of Completion is generated and appended — who signed, when, from where, and how they were identified.
- Seal
PAdES-B-LT, then B-LTA: the signature, its validation data and a trusted timestamp are embedded, so the document can still be verified after the certificate that signed it has expired.
Enforced by the database, not by remembering.
Tenant isolation implemented as a condition in application code is one forgotten clause away from a breach, and the forgetting happens in a query nobody has written yet. These are properties of the storage layer instead.
Every table carries a policy. The isolation is a property of the database, so it holds for a query nobody has written yet.
Events can be written and read. They cannot be updated or deleted — by us either.
A sandbox envelope is marked on every page and gets no seal. There is no signed-and-watermarked artefact and no unsigned-and-unmarked one; the two paths are exhaustive and mutually exclusive.
A recipient’s link gets them to their own envelope and nothing else. It is not an account, and it does not become one.
Leaving should cost an afternoon.
An export you have to request is a lock-in with a helpdesk in front of it.
- How long do you keep our documents?
- For as long as the account is open. We do not expire a sealed document, because the reason to keep one is that somebody may need it in five years — and a retention policy that quietly deletes evidence is worse than no policy.
- Can we get everything out?
- Every document and every audit trail, on any plan, in a documented format. Leaving should cost you an afternoon, not a negotiation.
- What happens if we close the account?
- Export first — the sealed PDFs are yours and they verify without us. Once the account is closed the data goes with it; a copy we kept “just in case” would be a copy you did not authorise.
- Who at Vumasign can see our documents?
- Access to production data is limited to the people who operate the system, for the purpose of operating it. There is no browsing, and there is no support tool that reads a document to help with a ticket.
The part of a security page that is usually missing.
Everything above this line asks you to take something partly on trust. This is where that is earned: a company willing to name what it does not have is making a claim about everything else it said.
We do not hold either, and we will not imply we do with a badge. When one is in progress, this page will say so with a date rather than a logo.
Nor are DocuSign, Dropbox Sign, Adobe or BoldSign, who all sell here. Accreditation matters in the narrow band where a statute demands a signature without naming its type — /is-it-legal names those documents rather than skipping past them.
When there is one, the summary goes here. A page that stayed silent until it had good news would not be worth reading.
Uptime and incidents are published at status.vumasign.com. Found something? Tell us — we would rather hear it from you than read about it.
Check the seal yourself.
Sign something, open the sealed PDF in Adobe Reader, and watch it verify without us in the loop.