Security and privacy you can prove.

A “looks good” in an email will not help you if a client later disputes the work. Stria’s security model exists to make an approval hold up months later — and to make each claim on this page traceable to a specific mechanism rather than an adjective.

Foundations under everything Stria stores

Isolated at the database, not the app. Row-level security scopes every query to the organization that owns the row, and a row’s organization cannot be changed once written. A bug in application code cannot move data between workspaces.
Least privilege by default. Clients take part through an unguessable link with no account and no database access. The anonymous role holds no table privileges at all; every anonymous action runs through a scoped server-side procedure that returns only public-safe fields and is rate-limited per IP.
Private files, short-lived links. Assets live in private storage and are served only through signed URLs minted server-side with a short expiry.
Yours to export and delete. A workspace can export every record it holds, including an inventory of its stored files. Deletion is available at organization and account level.

What makes a sign-off hold up

Email-verified. Before an approval is recorded, the signer enters a one-time code sent to their address, so the approval is bound to control of that inbox rather than to a click anyone with the link could make. Codes are stored only as a keyed hash under a server-side secret, so a database leak cannot recover an outstanding code.
Tamper-evident. Each sign-off stores a SHA-256 hash of exactly what was approved. If anything changes afterward, the hash stops matching.
Append-only. Sign-offs cannot be edited or deleted — database triggers reject the attempt. Once a deliverable is signed off it is frozen, and a signed deliverable cannot be deleted out from under its own record.
Server-captured context. The signer’s IP address and the timestamp are captured server-side at the moment of approval, never supplied by the browser.

What a sign-off record captures

The deliverable and its version, the content hash, the signer’s name and verified email, the server-observed IP and timestamp, and the exact consent text the signer affirmed. That record exports to a print-ready PDF, and anyone holding the hash can check it against the public verification page without an account.

Where card payments sit

Stria uses Stripe Connect Standard. Your connected Stripe account is the merchant of record and owns payouts, refunds, disputes and tax. Stria never holds your funds, and no card data touches Stria — card entry happens only on Stripe-hosted pages reached by a full redirect. That is what keeps this arrangement on the SAQ A side of PCI.

What we do not claim

The limits matter as much as the mechanisms, so they are stated here rather than in a footnote.

A Stria sign-off is not a legally-qualified electronic signature. There is no government-ID or identity-verification step. The alignment with ESIGN, UETA and eIDAS is documented element by element, at the simple electronic signature tier explicitly — not advanced or qualified — and it is not a legal opinion.
The content hash fingerprints the embedded resource’s URL and metadata, not the pixels of a file hosted somewhere else. If a client edits a linked Figma file after approval, the hash proves what was linked and approved, not that the remote file is unchanged.
Database backups and point-in-time recovery are platform settings on our hosting provider, not features Stria implements.

Compliance status, stated accurately

Stria is not SOC 2 certified and does not claim a completed SOC 2 examination. SOC 2 readiness work is underway: there is a tracked controls inventory where every control names the migration, database test or workflow that implements it, plus a written gap register with owners. Those are controls in place — not an audit result, and not evidence of operating effectiveness over an observation window. The readiness roadmap is published.