TracesOn holds sensitive compliance evidence for every organization on the platform. The same rigor we ask your team to bring to your own audit is built into how we run ours.
Every organization's data is scoped by org_id, enforced at the application layer on every query and backed by Postgres row-level security as a second, database-level guard. One organization can never read another's evidence — that boundary is non-negotiable.
Every upload creates a new, immutable artifact record. Once evidence is accepted as part of an audit, that artifact set is frozen forever — later uploads create new records rather than replacing what an auditor already reviewed.
Every status change — request created, evidence submitted, accepted, rejected — is written to an append-only event log with no update or delete path, even for administrative access. The chain of custody your auditor asks about is enforced at the database layer, not just application convention.
Row-level security is force-enabled on every organization-scoped and catalog table, with isolation policies that key off the authenticated session — not client input. It's a second guard behind the application layer, not a replacement for it.
Third-party integration tokens (such as Jira OAuth tokens) are encrypted at rest with AES-256-GCM. Platform secrets live in your hosting provider's secret manager — never in source control, and never exposed to client-side code.
Evidence files are stored in a private bucket with no public access. Every read or upload uses a short-lived signed URL scoped to that specific file and request — there is no persistent public link to your evidence.
We're working toward SOC 2 Type I certification and SAML SSO ahead of our mid-market rollout, and toward centralized secret management (Supabase Vault) for all customer-owned integration credentials. We'd rather tell you what's in progress than overstate what's done.
We take reports seriously. Email support@traceson.com and we'll follow up promptly.