Audit data retention reference

Automation orchestrator provides short-term audit data retention only and is not a long-term system of record. Audit event retention is managed at the destination layer, with each supported destination having independent retention controls and a minimum recommended retention period.

Two-tier retention model
Copy link

Automation orchestrator uses a two-tier retention model for audit data:

  • Tier 1 — Platform database (short-term): business_event and security_event type audit records are stored in the platform PostgreSQL database for up to 90 days by default. Contact your platform administrator to confirm the retention period configured for your deployment. This tier supports the Audit UI and compliance reviews within the retention window. The platform is not a long-term system of record. You must export data before the retention window expires.
  • Tier 2 — External OTLP backend (long-term): when OTLP forwarding is enabled, all audit event categories (including crud_event) are streamed in real time to your configured external observability backend. Retention in the external backend is governed by that system's retention policy, which you must configure to meet your compliance obligations.
Important

The platform is not a long-term system of record for compliance audit data. For multi-year retention requirements (SOX 7-10 years, HIPAA 6 years, GDPR variable), configure OTLP forwarding to an external observability backend before enabling audit logging in production.

Retention by destination
Copy link

The following table lists the retention control and minimum recommended retention period for each destination:

Destination Retention control Minimum recommended retention
Pod standard output OpenShift node log rotation (governed by cluster configuration and available node disk capacity) 30 days
LokiStack Retention policy configured in the LokiStack custom resource 30 days
External OpenTelemetry Protocol (OTLP) backend Retention policy configured in the external system 30 days (set to match your longest applicable compliance obligation)

These are platform-minimum retention recommendations — your organization's compliance obligations may require longer periods. Set retention at each destination layer to meet your longest-applicable compliance obligation before enabling audit logging in production. See the compliance framework guidance below for typical retention requirements by regulatory framework.

Compliance framework retention guidance
Copy link

The following table shows common compliance frameworks and their typical audit retention requirements. Configure your external OTLP backend retention policy accordingly:

Framework Typical retention requirement Notes
SOX 7-10 years Applies to financial records and audit trails for publicly traded companies.
GDPR Variable (typically 1-3 years, subject to data minimization principles) Audit records that reference personal data are subject to erasure requests. See the hard-delete model section for guidance on GDPR deletion handling.
HIPAA 6 years Applies to covered entities and business associates handling protected health information.
SOC 2 1 year minimum (audit period) Longer retention may be required by your auditor for continuous monitoring evidence.
Note

Consult your compliance team and legal counsel to confirm the applicable retention requirements for your organization and jurisdiction. Retention requirements vary by industry, data type, and regulatory authority.

Hard-delete lifecycle and audit data
Copy link

Automation orchestrator uses a hard-delete model. When you delete a resource, the platform permanently removes it from the database. Deleted resources and their associated data cannot be recovered from the platform.

Warning

Hard-deleted resources are not recoverable. If your compliance requirements demand long-term audit records of deleted resources, export audit data to external storage before deleting those resources or before the retention window for each destination expires.

The hard-delete model applies to all managed resource types, including users, workflows, credentials, role assignments, and service accounts. Audit events that reference a hard-deleted resource retain the resource_urn field in the event record, but the resource itself is no longer accessible through the platform API or UI. This makes audit events the authoritative durable record of deleted resource history.

CRUD event retention
Copy link

crud_event type audit events are generated by database triggers and forwarded to the OTLP channel only. They are not stored in the platform database and do not appear in the Audit UI at GA release.

CRUD events require OTLP forwarding for any retention beyond pod log rotation. To retain CRUD event data beyond pod log rotation, you must:

  1. Enable OTLP forwarding by setting otel.enabled=true in the platform configuration.
  2. Configure an external observability backend with a retention policy that meets your compliance requirements.

Pod stdout retains CRUD events only as long as OpenShift node log rotation permits, typically between 24 hours and 7 days depending on your cluster configuration.