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 trail is append-only and WORM-retained (write-once, read-many) in object storage with object-lock protection, so an entry cannot be altered or deleted before its retention window expires — by anyone, including a privileged operator.
Target-state — durable WORM immutability
The append-only design above is the committed contract. Compliance-grade object-lock immutability — the WORM retention mode that makes an entry undeletable by any operator before its window expires — is a Target-state control being hardened from the current governance-mode retention; not yet general. The binding label and gate are in Docs authority & product state. Audit entries survive a graph rebuild because they live on the
append-only event topics, not in any rebuildable view, and they survive a disaster because the audit store carries its own durable, locked 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 WORM-locked window so the compliance record outlives the operational clock.
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.