This is the inventory: every category of data TRUSTIVAN holds for a tenant, where it lives, whether it is encrypted, and how long it is kept. It is written from the schema and the retention job as they exist today — see Compliance evidence for the honesty rule this whole site follows, which applies here too: this page describes what the software does, not a certification about it.

​
Where data lives

One PostgreSQL database, one tenant boundary. Every table that holds a customer’s data carries an org_id (or organization_id) column, is under row-level security, and is reachable only through a Scope issued after authentication — see Tenant isolation. Redis holds transient queue and rate-limit state, never a customer’s security findings, and is not backed up (see Backup and recovery for why). There is no data residency option today: one region, one database, for every tenant. If your organization requires data to stay in a specific jurisdiction, that is a deployment question for self-hosting TRUSTIVAN, and a gap to raise with us directly rather than a setting to look for.

​
Categories

​
The audit-retention entitlement names two different things

audit_retention_days is sold and shown per plan (30/365/730 days), and it is real — but it governs usage/billing metering events (internal/retention/retention.go), not the identity audit trail itself. identity_audit_events is never swept by this window or any other: see Audit trail for why (append-only trigger, hash chain, and a hard rule in the retention job’s own comments — “the audit WINDOW is enforced; the audit TRAIL is not what it is enforced against”). In practice this means the audit trail outlives the plan’s advertised window rather than falling short of it — the retention page states this rather than leaving a reader to assume the number applies uniformly.

​
What is not yet enforced

  • Scan rows themselves (as opposed to the findings a scan produced) are not swept by the retention job; they are kept because findings reference them for lifecycle reconciliation. A long-lived tenant’s scan history grows without an independent cap today.
  • Data residency is not configurable, as above.
  • Off-host backup encryption key custody: see Backup and recovery for the current gap (the age identity that could decrypt an off-host backup is documented as needing to live off the backup host; verifying that in your own deployment is on you until this ships as an enforced control).

​
Getting your data out, or gone

  • Export your own tenant’s data: GET /orgs/current/export — see Delete an organization’s first step, which applies whether or not you intend to delete anything afterward.
  • Delete everything: deleting the organization cascades through every tenant table, audit rows included — see the same page for exactly what survives (one platform-level record of the erasure itself, holding none of your data).
  • Export the audit trail specifically: GET /audit/export, or subscribe to the audit.recorded webhook — see Audit trail.

​
See also