# Audit retention & SIEM

Every operation in the vault produces an immutable audit event. This page covers how audit events are emitted, how long they are retained, and how to forward them to your SIEM or log aggregation system.

## How audit events are emitted

The vault writes structured JSON audit events to standard output on the Orchestrator and Policy Server pods. Events include the actor, the resource, the action, the outcome (approved, denied, or error), and a UTC timestamp with millisecond precision.

Because events are written to stdout, your existing log collection agent (Fluentd, Fluent Bit, the AWS CloudWatch agent, or any equivalent) picks them up without any additional configuration on the vault's side. Route the output of Orchestrator and Policy Server pods to your SIEM in the same way you collect logs from any other Kubernetes workload.

:::note
Key Store pods run inside a Nitro enclave; their enclave-side output is surfaced through the runner container's stdout. Verify that your log collector captures all four containers in the Key Store pod.
:::

## Retention

Audit events are persisted to the Orchestrator database and are also available through `GET /v1/audit-logs` and CSV export. The vault does not prune them on its own, so authoritative long-term retention should live in your SIEM or log archive, sized to your compliance policy (for example, 90 days for SOC 2, 365 days for ISO 27001, or longer for financial-services regulations).

## What to forward and recommended alerts

Forward all structured output from Orchestrator and Policy Server pods. The events you most likely want to alert on:

| Event | Alert condition |
|---|---|
| Policy denial | Any signing request denied by Signing Policy |
| Admin enrollment | Passkey enrolled for any identity |
| Key creation or import | Any new key material introduced |
| Key deletion | Any key deleted |
| Policy change | Any change to Signing Policy or Administrative Policy |
| Freeze or unfreeze | Any key or identity frozen or unfrozen |
| Authentication failure | Repeated failures from the same identity |
| Backup operation | Any backup export event |

## Verifying audit completeness

The orchestrator provides a count of audit events for a given time range. Cross-reference this count against your SIEM's ingested event count periodically to confirm no events were dropped in transit.