Skip to content
Legal  ·  Security

Built to be trusted.

How the system is built, who processes the data, and what we do not claim. Effective June 2026.

Data governance isn’t a feature we bolted on; it’s the foundation. Customer and counterparty data sits on a bank-grade ledger, each party’s information isolated from every other’s, under audit logs that can’t be edited or erased. What follows is specific rather than reassuring, because a buyer’s security review cannot act on adjectives.

I. Separation is in the database, not the application.

The rule that keeps one party’s data away from another’s is enforced by the database itself. Thirty tables carry row-level security, under forty-seven policies, so a query that should return nothing returns nothing even when the application asks for it wrongly. An application bug can fail to show you what you are entitled to; it cannot show you what you are not. That is the whole reason the rule lives where it does.

Two records are append-only, enforced by database trigger rather than by convention: the event log, and the revision of a Stock item as it stood when someone bought it. UPDATE and DELETE against either one raise an exception and the transaction fails. Nobody at Estable has a path that quietly rewrites history, ourselves included.

The event log is also hash-chained. Each entry carries the SHA-256 of its own content joined to the hash of the entry before it, so an edit anywhere breaks every link after it. The chain can be walked end to end and checked on demand, and the check is a button on our own desk, not a promise on this page.

II. Access is per job, and it ends on its own.

A specialist firm never holds standing access to a member’s work. Access is granted for one job, recorded with who granted it, and it ends when that job closes or is cancelled, or at a ninety-day ceiling, whichever comes first. A member can end it sooner from their own page, and the firm loses sight of the job at once. Suspending a firm revokes every clearance it holds and takes everything it sells off Stock in a single recorded act.

III. Every request says what data it touches.

Before a member’s request goes anywhere, it states what the work will touch: internal business data, confidential data, or regulated data such as health records, payment cards or personal information. The desk puts forward only a firm cleared for that class.

Clearance follows a dated record each firm keeps current with us: a named security contact, cyber and errors-and-omissions insurance, a security report before any confidential work, and a business associate agreement before any health data. When a required item lapses, that firm’s items come off Stock automatically until it is renewed. The work itself runs inside the member’s own systems; there is no path for handing us a member’s operational data, and we do not ask for it.

IV. How the service is served.

Every response carries Strict-Transport-Security for two years, with includeSubDomains and preload, so a browser that has seen this site once will not speak to it unencrypted again. Insecure requests are upgraded, content-type sniffing is off, referrers are trimmed to the origin when they cross one, and the permissions policy denies camera, microphone, geolocation, motion sensors, screen capture and autoplay outright.

The signed-in surfaces are held to a tighter rule than the marketing pages: /market and /commerce are sent no-store, so nothing is written to a browser cache or an intermediary, and X-Frame-Options: DENY, so neither can be placed inside another site’s frame. Both are excluded from search indexes.

V. Identity, and what we never hold.

Signing in is by one-time link. A member may also set a passcode, and when they do it travels from their browser to our identity provider directly: no Estable server, function or log is in that path, and no endpoint we operate accepts a password at all. We cannot leak what we are never given.

VI. Who else touches the data.

Five companies process data on our behalf. Naming them is the point; a subprocessor list a buyer cannot see is not a control.

Vercel serves the site and runs the functions behind it. Supabase holds the database and the identity records. Resend carries transactional mail. Stripe takes payment, and card numbers reach Stripe without passing through us. Anthropic reads applications submitted through our public forms, to sort and route them: that call carries the company, the contact name and address, and the form as submitted. It is the one place where something a person typed leaves our own stack for a model, and we would rather say so here than have it found.

VII. What we do not claim.

We hold no SOC 2 report, no ISO 27001 certificate, and no third-party penetration test. We run no paid bug bounty. A company our size that told you otherwise would be describing an ambition, and a security review is the wrong place to find out which one you were reading.

What we offer instead is the specificity above, a codebase where these controls are written down beside the reasoning for them, and a standing willingness to answer a questionnaire in writing, by name, with a date on it. Ask for anything here in more detail and you will get it. When the audits exist they will be published on this page with their dates, and not before.

VIII. Reporting a vulnerability.

If you’ve found a security issue, tell us, we’d rather hear it from you than read about it later. Write counsel@estableco.com with the subject “Security,” the steps to reproduce, and anything we need to confirm it. We’ll acknowledge that we received it and keep you posted as we work it.

IX. Working in good faith.

We won’t pursue legal action against good-faith research that respects privacy, avoids degrading the service, and accesses no more data than is needed to demonstrate the issue. Give us reasonable time to fix what you find before disclosing it publicly. We don’t yet run a paid bounty; we do credit the people who help us, with their permission.

X. Machine-readable.

Buying on behalf of a company? estableco.com/procurement carries the entity, the W‑9, purchase orders and net 30, and how to get an MSA or a DPA executed.

Our disclosure contact is also published at /.well-known/security.txt, per RFC 9116. Anything not covered here goes to counsel@estableco.com.