The self-serve answer to a security review — request a DPA or ask a follow-up any time at [email protected].
Mucho Gusto is multi-tenant on a single shared Postgres database (hosted on Neon), isolated at the database layer with Postgres Row Level Security — every tenant-scoped table has FORCE ROW LEVEL SECURITY enabled and a policy that only ever admits rows matching the caller's own tenant id. This is enforced by Postgres itself on every query, not by application code remembering to add a WHERE tenant_id = … clause — a category of tenant-isolation bug that database-level RLS closes structurally rather than by convention. Embeddings used for feed/profile matching live in the same Postgres database (via pgvector), not a separate vector store.
All traffic between clients, our web/API services, and our database runs over TLS. Data at rest in our primary database is encrypted per Neon's own platform-level defaults; we have not yet independently audited or separately documented that guarantee on our own — ask us for Neon's current published materials if your review needs a primary source.
Sign-in is Clerk-delegated: Google sign-in, Microsoft sign-in, email/password, and Sign in with Apple on iOS, with phone/SMS or an authenticator app available as a second factor. An admin can require MFA org-wide and restrict which sign-in methods are allowed for their organization. Verified email domains let a work Google or Microsoft account land a new hire directly in the right org with no invite step.
For automated provisioning, we ship a real SCIM 2.0 endpoint (Users + Groups, RFC 7644) that any SCIM-compliant identity provider can connect to, with a per-tenant bearer token minted and rotated from the admin console. We do not offer SAML-based single sign-on today — Google and Microsoft sign-in are OAuth connections, not a SAML integration, and we say so plainly here rather than overclaiming "SSO."
Vendors that handle tenant data on our behalf, and what each one handles:
We are actively collecting a signed DPA and current SOC 2 (or equivalent) report from each vendor above; that collection is in progress, not complete, as of this writing. If your procurement process needs a specific vendor's current status or documentation, ask — we'll tell you exactly where that vendor stands rather than assume.
Mucho Gusto is hosted on Render, which auto-deploys and runs our backend and web services. We do not currently publish a formal uptime SLA, and we do not yet run automated uptime or error-rate monitoring — we're a small team and want to be upfront about that rather than imply a guarantee we can't back up today. If uptime commitments are a hard requirement for your organization, tell us — that's useful signal for what to build next.
We run a written incident response plan: incidents are classified by severity (any confirmed or suspected cross-tenant data exposure is treated as Critical), the response is contained and root-caused before being considered resolved, and — for any incident involving actual or reasonably suspected exposure of a tenant's data — we target notifying that tenant's admins within 72 hours of confirming it meets that bar. We're a one-person engineering team today, which the plan is written around honestly rather than implying a larger on-call organization.
We run a quarterly self-review of who holds admin privilege in the product, who has access to our authentication provider's dashboard, which SCIM tokens and directory-sync connections are still in active use, and where our one cross-tenant-bypass database role is invoked in application code — logged each quarter, including when a review finds nothing to change.
Need a Data Processing Agreement, a specific vendor's subprocessor status, or anything else for your security review? Email [email protected] and we'll follow up directly — there's no ticketing system standing between you and a real answer.
See also: Privacy Policy, Terms, Belonging Score methodology.