Order-level audit trail
Every state transition records its actor, timestamps, and metadata — consent, signature, notarization, delivery, seal. The customer-facing certificate is generated from this record, not alongside it.
Trust center
Security claims should come with evidence.
Every sealed document can be checked independently in Adobe Acrobat and through the public verifier. This page shows the controls, audit model, subprocessors, and certifications we have—and clearly labels what we do not have yet.
- Independent PDF validation
- Tamper-evident audit trail
- No unearned badges
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.
Prefer not to install anything? Drop the PDF on our public verify portal — free, no account, and it adds the evidence timeline Acrobat can't show: consent, signatures, seal, notarization, and delivery tracking.
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 43 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
A sealed document should be treated like the vault copy of a record — encrypted on every path, retained for years, and reachable only after we have checked who is asking.
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
Customer document buckets block all public access — every document is streamed through our API only after an authorization check, and signing links expire 24 hours after they are issued. Time-limited signed URLs are used only where a delivery rail requires them (for example, handing a fax carrier a document for a single transmission).
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 deployed service runs under its own dedicated service account, granted only the access its role requires — the malware scanner can't reach the database, the agent mesh can't touch sealed documents, and nothing shares the API's credentials.
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.
ARCHITECTURE
The path a document actually takes
Six hops, each with its guarantee. Take this diagram into your vendor review — then check hop six yourself on the verification portal.
- 1
Browser
TLS 1.2+ only. Session cookies are HttpOnly; the order link is a high-entropy bearer capability.
- 2
Edge (Cloudflare)
Public /api/* traffic proxied with an origin shared-secret check; rate limits on every public write.
- 3
API (Cloud Run)
Stateless .NET service. Money paths verify payment server-side before releasing anything; internal jobs are OIDC-authenticated, not edge-reachable.
- 4
Postgres (Cloud SQL, regional)
Regionally replicated with point-in-time recovery and deletion protection. The order state machine and audit log live here.
- 5
Documents (Cloud Storage)
Versioned buckets with public-access prevention. Uploads are malware-scanned (event-driven ClamAV) and DLP-classified — category names only, never content, in logs.
- 6
Seals (Cloud KMS)
Sealing keys are Cloud KMS-backed and non-exportable. The sealed PDF and its SHA-256 feed the public verify portal.
Secrets are mounted from a managed secret store, never baked into images. Deploys ship by immutable image digest with the source commit verifiable at /api/version.
GOVERNANCE
Administration that leaves a record
Event outbox & timeline
Side effects flow through a transactional outbox, so an event either happened and was recorded or did not happen — no ghost emails, no unrecorded webhooks.
Webhook reliability ledger
Outbound webhooks are signed and every delivery attempt is recorded with retries. Integration events get the same evidence discipline as documents.
Operations paging
Stalled sessions, failed deliveries, and at-risk orders page a human automatically. Access to admin actions requires a verified admin identity, revocation-checked on every state change.
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 tamper-evident 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. Customer document buckets block all public access — your documents are served only through our API, which checks your authorization before a single byte is streamed. Each backend service runs under its own dedicated service account, granted only the access its role requires. (Site imagery and public form templates live in a separate public assets bucket that never holds customer documents.)
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 — or drop it on the verify portal — and check our work.