TRUST CENTER
Security & Trust
Anyone can put a padlock icon on a marketing page. We'd rather hand you the tools to check our work: every document we seal can be verified in Adobe Acrobat, by anyone, without asking us. This page explains exactly how — and is honest about what we're still working toward.
DOCUMENT INTEGRITY
Don't trust our seal. Verify it.
Every completed document is sealed with an asymmetric signing key held in Google Cloud KMS. The private key never leaves Google's infrastructure — our servers send a hash of the finished PDF to KMS and receive a signature back. That signature is embedded in the document as a CMS (PKCS#7) digital signature covering the PDF's ByteRange.
What that buys you is simple: change one byte of a sealed document and the seal visibly breaks in any standards-compliant PDF validator. The check runs on your machine, not ours — which means our biggest security claim is one you never have to take on faith.
CHECK IT YOURSELF — TWO MINUTES
- 01Open the sealed PDF in Adobe Acrobat — the free Reader is enough.
- 02Open the signature panel.
- 03Acrobat validates the CMS signature over the document's ByteRange.
- 04If anything changed since sealing, the signature reports invalid. That's the whole test.
CERTIFICATE OF COMPLETION — WHAT'S ON IT
Every order ships with one. It's the paper trail of the electronic trail:
- Envelope reference
- The order and envelope IDs the certificate belongs to.
- Consent record
- Each signer's ESIGN 101(c) consent, with the exact UTC timestamp it was given.
- Document hashes
- SHA-256 of the original upload and of the sealed PDF — compare them yourself.
- Event timeline
- Every view, field completion, and signature, timestamped in UTC with the IP address it came from.
- Seal details
- When the KMS seal was applied and the certificate it chains to.
AUDIT TRAIL
An event log that can't quietly rewrite history
Every envelope writes an append-only event log. Each event carries the SHA-256 hash of the event before it, so the records form a chain — rewriting any entry breaks every link after it. Events are recorded as they happen, in UTC, with the IP address they came from.
CONSENT
Signer agrees to conduct business electronically (ESIGN 101(c))
VIEWED
Signer opens the document, with UTC timestamp and IP
SIGNED
Each signature and field completion as it happens
SEALED
The moment the KMS digital seal is applied
sha256(event N) ⊂ event N+1 — the chain is the tamper alarm.
IDENTITY VERIFICATION
Who signed matters as much as what was signed
Knowledge-based authentication
Before a notarization, signers answer a timed quiz generated from public records — questions only the real person should be able to answer.
Government-ID credential analysis
Both sides of a government-issued photo ID are captured and analyzed for authenticity markers before the session begins.
A commissioned notary, live
A state-commissioned notary confirms identity on camera, administers any oath, and watches the signing. RON sessions are available through notaries in 44 jurisdictions, recorded as each state's law requires.
Notarial acts are performed by independent, state-commissioned notaries under the laws of their commissioning state — not by SignSealShip.
ENCRYPTION & STORAGE
Encrypted moving, encrypted resting, expiring links
IN TRANSIT
Every connection to the platform runs over TLS. There is no unencrypted path to a document.
AT REST
Documents and records are encrypted at rest on Google Cloud infrastructure.
ACCESS
Documents are served through short-lived V4 signed URLs generated per request — links expire in minutes and can't be shared usefully.
RETENTION
Sealed documents are kept in a dedicated 7-year retention bucket, so the record outlives the transaction that created it.
INFRASTRUCTURE
Built on Google Cloud, wired to fail closed
The platform runs on Cloud Run (stateless, autoscaled application containers), Cloud SQL (managed PostgreSQL), and Cloud KMS (the sealing keys described above). Boring, managed, and patched by Google — exactly what you want under legal documents.
Each service runs under a least-privilege service account: the component that sends email can't read the database, and the component that prints labels can't touch sealed documents.
WEBHOOKS — FAIL CLOSED
Every inbound event from a vendor (payments, notary sessions, shipping, mail) must pass signature verification before it's processed. If a vendor's verification isn't configured, its route simply doesn't exist in production — a forged event has nothing to talk to. Fail closed, never open.
LEGAL COMPLIANCE
ESIGN, UETA, and the RON rules of your state
Consent first
Before anyone signs, we capture affirmative consent to do business electronically, as ESIGN section 101(c) requires. The consent — and its timestamp — becomes the first entry in the audit trail.
ESIGN + UETA
Signatures are attributed to identified signers, tied to intent, and retained in reproducible form — the elements both statutes care about, built into the flow rather than bolted on.
State-by-state RON
Remote online notarization rules differ by state and document type. We check the combination before you pay and refuse what a state doesn't allow — see state availability.
SignSealShip is a technology platform, not a law firm, and does not provide legal advice. Notarizations are performed by independent commissioned notaries or approved RON provider partners. RON availability varies by state and document type.
THE HONEST TABLE
What we've built, what we haven't — in one table
If it isn't marked "built in" here, we don't claim it anywhere. Roadmap items stay roadmap items until an auditor says otherwise.
| ITEM | STATUS | THE DETAIL |
|---|---|---|
| ESIGN Act (15 U.S.C. § 7001) | BUILT IN | Consent captured per § 101(c) before any signing, signatures attributed to identified signers, records retained and reproducible. |
| UETA | BUILT IN | Intent, attribution, and record integrity handled by the signing flow and audit trail. |
| Tamper-evident sealing (CMS / PKCS#7) | BUILT IN | Every sealed PDF carries a cryptographic signature you can verify in Adobe Acrobat — no SignSealShip account needed. |
| SHA-256 hash-linked audit trail | BUILT IN | Append-only event log on every envelope; each event chains to the previous one. |
| RON state rules | BUILT IN | Deterministic state-and-document rules checked before you pay — restricted combinations are refused, not fudged. |
| SOC 2 Type II | ON OUR ROADMAP | Not yet certified, and we won't imply otherwise. Until then, this page tells you exactly how the platform is built. |
| ISO 27001 | NOT CERTIFIED | We don't hold this certification and don't claim it. |
SUBPROCESSORS
Who else touches your data, and why
Every category of service provider that touches customer data, and exactly what its job requires it to see. Operational partners are listed by role; business customers can request the fully named subprocessor list under a data-processing agreement.
| SUBPROCESSOR | WHAT THEY DO | DATA THEY TOUCH |
|---|---|---|
| Google Cloud Platform | Infrastructure — Cloud Run, Cloud SQL, Cloud KMS, storage | Documents, account data, audit records |
| Stripe | Payment processing | Card details (entered directly with Stripe — they never touch our servers), billing contact |
| Remote online notarization network partner | Live RON sessions with independent, state-commissioned notaries | Session documents, identity verification results, session recordings |
| Shipping API partner | Carrier labels and live tracking (USPS, UPS, FedEx) | Recipient names and delivery addresses |
| Print-and-mail fulfillment partner | Automated printing and mailing of completed-document copies | Printed documents, recipient addresses |
| Transactional email provider | Signing links, receipts, and order notifications | Email addresses, order notification content |
RESPONSIBLE DISCLOSURE
Found something? Tell us. We'll listen.
If you believe you've found a vulnerability in SignSealShip, email us directly — include steps to reproduce if you can. A human reads every report, we'll acknowledge yours, and we won't pursue action against good-faith security research.
security@signsealship.comSecurity questions, answered plainly
How do I verify a sealed document myself?
Open the sealed PDF in Adobe Acrobat (the free Reader works) and open the signature panel. You'll see the SignSealShip platform seal — a CMS (PKCS#7) digital signature applied with a Google Cloud KMS asymmetric key. Acrobat validates it against the document's ByteRange, so you get an independent answer about whether the document has been altered since sealing. You don't need an account with us, and you don't need to take our word for anything.
What happens if someone edits a document after it's sealed?
The seal breaks, visibly. The CMS signature covers the document's bytes via the PDF ByteRange mechanism, so changing even a single byte causes Adobe Acrobat and other PDF validators to flag the signature as invalid. The SHA-256 hash of the sealed document is also recorded on the Certificate of Completion, so you can compare hashes independently of any PDF viewer.
Is SignSealShip SOC 2 certified?
Not yet — SOC 2 Type II is on our roadmap, and we won't claim a date until an auditor gives us one. In the meantime we publish our subprocessor list and architecture on this page, and we lean on something a badge can't give you: every document we seal is independently verifiable in Adobe Acrobat, by anyone, forever.
How long do you keep my documents, and who can access them?
Sealed documents live in a dedicated retention bucket for 7 years, encrypted at rest on Google Cloud. Access goes through short-lived V4 signed URLs generated per request, and each backend service runs under a least-privilege service account that can only touch what its job requires.
How is my identity verified for an online notarization?
Two layers before the notary ever sees you: a knowledge-based authentication quiz generated from public records, and credential analysis of your government-issued photo ID. Then a live, state-commissioned notary confirms your identity on camera and the session is recorded as their state's RON law requires. Notarial acts are performed by the commissioned notary, not by SignSealShip.
How do I report a security vulnerability?
Email security@signsealship.com with steps to reproduce. A human reads every report, we'll acknowledge yours, and we won't pursue action against good-faith research. No forms, no gatekeeping.
The proof is in the signature panel.
Seal a document tonight, then open it in Acrobat and check our work.