Privacy Data Catalog

This catalog is the human-readable copy of the platform's machine-readable privacy catalog: direct personal-data locations, why each field exists, and what the privacy.subject.erased and privacy.retention.enforced projections do to tenant read surfaces. Unless noted, a subject-access export (below) returns every matching row for that location.

Default non-audit retention runs every 24h, using these class windows: owners 17520h; identities/certificates/approvals/profiles/attestations 9528h; SSH keys/agents/agent offboarding evidence 4320h; and access subjects/PAM subjects 2160h. Governance, discovery, notification, remediation, compliance-schedule, ownership-exception, and incident free-form evidence follows the 397-day operational evidence window unless an operator configures a shorter policy. OIDC pre-login metadata is ephemeral and expires after 10m. Browser-session rows expire at the configured browser-session TTL; an expired cookie cannot authorize a request, and the next session creation for the same tenant deletes expired rows. Operators can override the other classes via the TRSTCTL_PRIVACY_RETENTION_* settings (docs/configuration.md).

Read-model snapshot cache

Read-model snapshots are accepted only as one complete capture generation. Every tenant row carries the same projection head, capture ID, expected tenant count, and digest of the exact sorted tenant IDs. A missing target row, mixed capture, legacy format, or crash-partial capture is ignored before any read-model table is truncated; a cold restore then starts from checkpoint zero and replays sanitized event history. After erasure completion, the periodic writer may create a new snapshot from the already-sanitized read model.

In the console (/privacy)

The web console exposes this stack as Evidence privacy at /privacy (see The web console). It answers the boundary first: privacy:read can review tenant evidence, privacy:write is required to change retention or erasure evidence, retention is named per catalog entry, and every request stays inside the current tenant. Exact controls stay in four closed sections and load only when an operator opens them:

• Policy and data map — browse the maintained rows from GET /api/v1/privacy/catalog, including location, owner, purpose, and retention class.
• Subject rights — enter a subject and optional reason, then review the exact tenant-scoped match at POST /api/v1/privacy/subject-erasures/preview before erasing. The review returns the normalized request, subject ref, per-class and total record counts, archive-attestation and active-legal-hold counts, a tenant-bound fingerprint, the later writes, and recovery/verification steps. It writes no row or event and makes no external call. Confirmation calls POST /api/v1/privacy/subject-erasures and shows the count erased from the privacy.subject.erased projection. Export a subject's cataloged record counts through POST /api/v1/privacy/subject-exports. Secret values and token material are not rendered. The long-running erasure receiver uses its dedicated history/recovery fence; it does not hold an idle route-wide tenant-key transaction while rewriting history. Its cached HTTP result is still sealed separately under the tenant key after completion. If that short sealing step cannot acquire cryptographic access, retry the same request with the same Idempotency-Key; the durable receiver reconciles instead of erasing twice.
• Archive removal evidence — inspect or record tenant-scoped proof that a backup or signed audit archive was deleted, cryptographically shredded, or retained under legal hold through GET and POST on /api/v1/privacy/archive-erasure-attestations.
• Retention jobs — review the effective tenant cutoffs and exact currently eligible counts at POST /api/v1/privacy/retention-runs/preview, then confirm POST /api/v1/privacy/retention-runs. The preview is an effect-free read. The history shows run id, cutoffs, affected records, and requester on top of the scheduled 24h default. Already-pseudonymized rows are excluded from later affected counts, so a fresh review reflects only work that remains. Like direct erasure, the potentially long retention receiver does not hold an idle route-wide tenant-key transaction; its idempotency response remains independently tenant-sealed and replay-bound.

Opening the page does not eagerly fetch these evidence sets. This keeps the default view short and avoids moving tenant evidence into the browser before the operator asks to review that section.

Data-subject access and portability

Beyond erasure and retention, an operator answering a data-subject access / portability request can export every record tied to a subject in one tenant-scoped call:

POST /api/v1/privacy/subject-exports
{ "subject": "alice@corp.example.com" }

The response collects the subject's owners, identities, certificates (matched on subject CN or SAN), SSH keys, attestations, tenant members, and API tokens (the token hash is never included — only the principal subject, scopes, and lifecycle timestamps), plus dual-control approvals (requester and approver ties) and a per-category counts map. It is a read — it changes no state, carries no Idempotency-Key, and reads under PostgreSQL row-level security for the caller's tenant only: a subject in another tenant with the same name is never returned. It requires the privacy:read permission.

This is the inverse of subject erasure (POST /api/v1/privacy/subject-erasures): export discloses the subject's data, erasure removes it. Both are event-sourced (privacy.subject.erased / privacy.retention.enforced); export is a pure read and emits no event.

Recovery and verification

Direct-data erasure and completed retention pseudonymization are intentionally irreversible. Recovery therefore means finishing safely, not restoring personal data:

1. Export any records policy allows you to retain, and record backup or signed audit-archive disposition before erasing direct operational data.
2. If an erasure response is interrupted, retry the unchanged request with the same Idempotency-Key. The durable operation returns the original result instead of erasing twice. On restart, trstctl completes any prepared history rewrite before normal service resumes.
3. Read the erasure or retention history, repeat the effect-free review, and inspect the audit event. The raw subject must be absent while pseudonymized security evidence remains verifiable. Raw-subject export and repeat erasure review exclude already-pseudonymized member and token rows, so retained revocation/offboarding evidence does not look like unfinished erasure work.

An archive legal_hold is not silently overridden. The erasure review names active holds and explains that the held artifact remains; direct operational erasure and archived-artifact disposition are separate evidence boundaries.