How we protect your documents, your signatures, and your clients' information — and how a counterparty can check an executed document without taking our word for anything.
Last reviewed: August 2026
When the last recipient finishes, the PDF, every value written into it, every signer and every timestamp are hashed into one fingerprint. Change any of it afterwards and the fingerprint stops matching.
The verification key is published, and the evidence travels with the document. A lender, title company or opposing agent can check a signed file with no account and no call to us.
No account can see another account's forms, properties, documents or clients. Neither can our own staff — not without your administrator's permission, and it expires.
The moment the last recipient signs, we build a single record of exactly what was executed: the bytes of the PDF itself, every field value with the time it was signed, and every signer with their role and their signing time. That record is hashed with SHA-256 into one fingerprint — the seal.
Because the fingerprint covers the file and what was written into it and who wrote it and when, it answers all four questions at once. It is rebuilt from scratch every time anyone asks whether a document is intact, so nothing is taken on trust from an earlier check.
A fingerprint on its own only proves a document hasn't changed. Two more steps make it evidence:
Both happen in the background, so a signer never waits on them, and the platform refuses to sign a seal it cannot first re-verify. If a timestamp authority is briefly unreachable, the job retries rather than attaching a claim we can't stand behind — and the certificate says pending rather than claiming a signature that doesn't exist.
| If someone… | What happens |
|---|---|
| Edits a value in a signed document | The rebuilt fingerprint no longer matches. The document reports as altered. |
| Swaps the stored file for a different PDF | The PDF's own hash is inside the seal. Mismatch, even if every other detail matches. |
| Adds or removes a signer | The signer list is part of the fingerprint. Mismatch. |
| Backdates a signing time | Signing times are part of the fingerprint. Mismatch. |
| Obtains a read-only copy of our database | They cannot forge a seal. The signing key is not in the database. |
| Compromises our servers outright | They cannot export the key or forge past seals, and the third-party timestamp still binds the original fingerprint to a time outside our control. |
Every page of a completed document carries its own certification stamp up the left edge, so a printed page can't be quietly substituted for another:
Signed via Rize Ink · ENV-1042 · Seal 9f2c4b7ae1d03f86 · Page 3 of 11
Alongside the signed copy, the agent and every signer can download an evidence package — a small JSON file containing the sealed record, the fingerprint, our signature over it, the timestamp token, and the address of the public key. Two public endpoints do the rest:
GET https://rizeink.com/.well-known/rize-seal-public-key.pem
POST https://rizeink.com/verify/seal
Post the evidence package — and, if you have it, the PDF you were sent — and you get back four independent answers: the record matches its fingerprint, this file is the one that was sealed, the fingerprint carries a valid signature from the published key, and a trusted authority timestamped it. That check reads nothing from our database, so it keeps working whether or not you have an account with us, and it works the same way on documents signed years ago.
One honest difference. A Rize Ink signature is not embedded in the PDF as a PKCS#7 / PAdES signature, so Acrobat will not show a blue "signature valid" bar. The evidence lives beside the document instead, where a third party can verify it independently. It's a deliberate choice, and worth knowing before a counterparty asks.
Every step of a signing is recorded with its time, the IP address it came from, and the browser used. The trail is printed on both the on-screen and PDF Certificate of Completion.
| Event | Recorded when |
|---|---|
| Sent | The request goes out to a recipient |
| Opened | The recipient's email client loads the message |
| Viewed | The recipient first opens the signing page |
| Consent accepted | The recipient accepts the ESIGN disclosure, with the version they accepted |
| Field signed | Each individual mark — this person, this kind of mark, this page |
| Completed | A recipient finishes their part |
| Reminder sent | A reminder is emailed |
| Send canceled | A send is called back and the links stop working |
| Document re-opened | A signed document is re-opened for edits |
Signatures are captured under the U.S. ESIGN Act and applicable state UETA. Before anyone can sign, they see the Electronic Records and Signatures Disclosure and tick an explicit intent-to-sign box; we record when they consented, from where, and which version of the disclosure they were shown. Times on the certificate are rendered in the signer's own time zone, captured at consent.
If an agent needs to change a document people have already signed, nothing is overwritten in place. The executed copy is archived first — its own flattened PDF and its own frozen evidence package, verifiable forever through the same public endpoint — and only then are the signatures cleared and the document returned to draft. Recipients keep a route to what they signed, including earlier executions, because a signed record has to stay reachable to the person who signed it.
Everyone signing sees fresh paperwork and gives fresh consent. The re-opening itself is an audit event.
Our people have no standing access to your account. From our internal console staff can see that your account exists, its name and type, how many users and transactions it has, whether it's paused and whether billing is in order — counts, not contents. An operator signed in as themselves sees an empty dashboard and gets a refusal on anything belonging to a customer.
The only way a member of our staff can work inside your account is with your permission. They ask and say why; your account administrator decides and chooses how long the permission lasts. While it's open, our operator sees your workspace as one of your own users would, and anything they change is changed under that user's name. You can end it in one click, which signs them out immediately, and it expires by itself regardless. Every request, decision and visit — including any attempt that was refused — is recorded on your Support access page.
Everyone invited to sign gets an account on their email address, so what they signed stays reachable to them. That access — for the sender and every signer — lasts five years from the transaction's completion, or from its last signature where it never completes. At the end of that period access is revoked for everyone and the records are archived: kept only to meet legal obligations, and reachable through no account, signing link or export.
The in-app event log for a document that is both completed and sealed is pruned about 18 months on, which shortens no signing record: by then the trail is written into the sealed PDF's Certificate of Completion and into the evidence package, and those verify without our database. Events for documents still in flight are never pruned on that schedule. The full retention and deletion schedule is section 10 of the Privacy Policy.
Card details are handled by Stripe on Stripe's own pages, and updates and invoices go through Stripe's hosted billing portal. Card numbers never reach our servers, so there are none for us to store or lose.
The application runs on managed U.S. infrastructure with restricted production access, encrypted transport, encrypted document storage, centralized logging and regular backups. The complete, contractual list of technical and organizational measures — access control, encryption, application and infrastructure security, data separation, logging, availability, vendor review and secure deletion — is Annex 2 of our Data Processing Addendum, which also sets out how quickly we notify you of a security incident and how subprocessors are reviewed and announced.
Stated plainly, because a security page that only lists strengths isn't much use:
If you think you've found a vulnerability, email security@rizeink.com with enough detail to reproduce it — what you did, what you expected, and what happened instead. A real person reads it, and we'll come back to you.
Please stay inside your own account and your own data while you look: don't access, modify or store anyone else's, and don't run destructive tests or automated load and scanning against production. If you land in someone's account or documents by accident, stop, and tell us what you saw. Testing beyond those limits isn't authorized — see the Acceptable Use Policy.
Rize Ink