Audit logs¶
Venturi keeps an immutable, append-only audit trail of every consequential action in your tenant: administrative mutations, exports, access decisions, overrides, configuration changes, and support sessions. The trail is written to your object storage, write-only from Venturi, and read-accessible to your security team. Venturi has no delete or update path to it. This is the record your auditor reconciles against, and it is the substrate of Venturi’s SOC 2 control set.
The audit log is yours, not Venturi’s
The admin audit trail is written append-only to customer-controlled object storage. Venturi can append; it cannot rewrite history. An auditor can verify that property directly from the storage policy; it is enforced by architecture, not asserted in a contract.
What is recorded¶
Every security-relevant and consequential action emits an audit event. The set includes, at minimum:
| Category | Examples |
|---|---|
| Authentication | Sign-in, sign-out, every auth failure, MFA/step-up challenges, SSO-only enforcement, session revocation |
| Authorization | Every authorization denial, role and role-binding changes, custom-role authoring, delegation start/end, impersonation start and each impersonated action |
| Identity lifecycle | Invite, provision (manual/SCIM/JIT), suspend, deactivate, off-board, ownership transfer, recertification attest/downgrade/revoke |
| Provisioning | SCIM create/update/deprovision, IdP/SCIM configuration changes, credential and API-key rotation |
| Governance | Pricing, policy, and budget changes; manual attribution overrides; intervention lifecycle transitions; dispute resolutions |
| Data & exports | Export-job create and deliver; dashboard and report access; deployment-mode changes |
| Privacy | Erasure (crypto-shred) with deletion certificate; legal-hold placement and release; retention-compliance reports |
| Support | Break-glass request, approval, MFA evidence, every accessed resource, expiry, and revocation |
Each event carries a consistent set of fields: actor, action, target, timestamp, outcome, tenant, source IP where applicable, and a before/after where a value changed. Actor and subject references are pseudonymized (recorded as opaque, stable identifiers) so the trail remains useful for investigation while limiting personal data.
No prompt or completion content, ever
The audit log records that an action happened and who did it, never the content of any AI request. Venturi’s pipeline has no field for prompt or completion text anywhere, and the audit trail is no exception. Audit entries carry actor, action, target, and details only; no telemetry payload.
Immutability and tamper-evidence¶
The audit writer is append-only in application behavior and writes to customer-controlled object storage with Object Lock enabled:
- Governance mode is the default. It blocks ordinary mutation and deletion, while a specifically authorized storage administrator can bypass retention.
- Compliance mode is available for deployments that require root-resistant retention. Objects cannot be deleted or shortened before expiry, including by the account root user. The standard compliance retention is 5 years.
These modes are not interchangeable. A page or evidence packet must identify the deployed mode and retention period instead of using “WORM” alone. Audit entries survive a graph rebuild because they live on append-only event topics, not in a rebuildable view, and the object store has retention independent of operational data.
This immutability is precisely what makes the trail trustworthy for a repudiation defense: if an actor later denies a configuration change, an override, or an export, the immutable record settles it.
Retention¶
The audit trail is retained separately from operational data, under its own named lawful basis:
- Operational data follows the platform default of 13 months (a 12-month operational cycle plus one reconciliation period), or a tighter tenant override where you set one.
- Audit and override records are retained under a dedicated, longer object-lock window so the compliance record outlives the operational clock. The evidence names Governance mode or Compliance mode and the configured duration.
When a data subject’s personal data is erased via crypto-shred (≤30-day SLA), the audit trail keeps only a pseudonymized, non-personal record that the action occurred, which is how the immutable audit log and the right to erasure coexist without contradiction. A legal hold can pin specific records, a subject, or a tenant scope so they are skipped by both the retention worker and the erasure pipeline for the hold’s bounded, reviewed duration; placing and releasing a hold is itself an audited, fail-closed action.
Reading and exporting the log¶
Your security team reads the audit trail directly from the object store and from the audit-log viewer in the admin console. Typical uses:
- Investigate an incident: filter by actor, target, action, or time window to reconstruct exactly what happened.
- Review access changes: see every role binding, delegation, impersonation, and recertification decision over a period.
- Reconcile an export: trace a chargeback export back to its creation event, the actor, and the parameters used.
- Evidence a control: an Auditor grant gives time-boxed, read-only access to the trail and the evidence chain so a reviewer can reproduce a control end-to-end.
The trail is also part of your tenant data export and is included in the final export at offboarding, so the compliance record leaves with you.
How it supports your compliance program¶
The audit subsystem is the backbone of Venturi’s controls posture:
| Standard | How the audit trail contributes |
|---|---|
| SOC 2 | The immutable trail is the evidence layer for access, change-management, and monitoring controls. Venturi’s stated posture is SOC 2 Type I readiness/report target; not yet held, with a Type II observation window targeted to follow. |
| GDPR / CCPA | Auditable evidence of access, lawful processing, erasure (with deletion certificates), and legal holds, with personal references pseudonymized. |
See Security, privacy & compliance for the full controls posture and how to run a security review.
Next steps¶
- Manage who can read the trail in Roles & RBAC.
- Configure identity and policy events at their source in the admin console.
- Review the trust center with your security team: Security, privacy & compliance.