> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ankra.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Audit Export
> Export the organisation audit trail as CSV or JSON, forward it to your SIEM or evidence store, and keep records beyond the platform retention window.
The [Audit Log](/guides/audit-log) is Ankra's append-only record of every administrative change. Export takes that record out of the platform so you can retain it on your own terms, feed it to a SIEM, or attach it to an audit response.
Exporting is the mechanism that turns the audit log from a troubleshooting view into compliance evidence, because evidence has to outlive the platform's retention window and live somewhere your assessor can reach.
***
## What the export contains
Each row is one audit entry, with the same fields the audit viewer shows:
| Column | Contents |
| --------------- | --------------------------------------------------------------------- |
| `created_at` | UTC timestamp of the action |
| `user_email` | The acting member's email address |
| `user_id` | The acting member's stable identifier |
| `action_type` | What was done, for example a role assignment or credential change |
| `resource_type` | The kind of resource acted on |
| `resource_id` | The specific resource |
| `ip_address` | Source IP the action came from |
| `cluster_id` | The cluster the action applied to, where the action is cluster-scoped |
| `cluster_name` | That cluster's name at export time |
| `details` | Structured detail of the change, as compact JSON |
In CSV the `details` column holds a JSON document, so keep the file quoted and parse it with a real CSV reader rather than splitting on commas - the details routinely contain commas and newlines.
Cell values that would otherwise be interpreted as formulas by a spreadsheet application are neutralised before they are written, so opening an export in a spreadsheet does not execute anything an actor put in a resource name.
***
## Permissions
Export is gated by the same audit read permission as the audit viewer, held by **owners** and **admins** by default and available to [custom roles](/guides/roles-and-access). A caller without it receives a `403` naming the missing permission.
Granting the audit read permission to a compliance or security function lets them pull evidence themselves without broader administrative access, which is usually what you want.
***
## Exporting from the portal
Go to **Organisation** → **Settings** → **Audit Log**.
Narrow by user, action type, resource type and date range. The export follows the filters currently applied, so filter first.
Choose the CSV or JSON export action. The file downloads with the organisation and date in its name, for example `audit-log--2026-08-13.csv`.
***
## Exporting via the API
The same export is available to scripts and scheduled jobs, which is how most teams feed a SIEM. Authenticate with an [API token](/reference/tokens) belonging to a member who holds the audit read permission.
```bash theme={null}
curl -sS \
-H "Authorization: Bearer " \
"https://platform.ankra.app/org/organisation/audit-logs/export?format=csv&start_date=2026-07-01&end_date=2026-07-31" \
-o audit-log-july.csv
```
Supported query parameters mirror the viewer's filters:
| Parameter | Purpose |
| ------------------------- | ----------------------------- |
| `format` | `csv` (default) or `json` |
| `start_date` / `end_date` | Bound the window, as dates |
| `user_id` | Limit to one member |
| `cluster_id` | Limit to one cluster |
| `action_type` | Limit to one kind of action |
| `resource_type` | Limit to one kind of resource |
| `search` | Free-text match |
Full request and response detail is in the **API Reference** tab.
***
## Row cap and truncation
A single export returns at most **100,000 rows**. When more rows match your filters, the export is truncated to the newest ones and says so:
* **CSV** responses set the `X-Ankra-Export-Truncated: true` response header.
* **JSON** responses carry a `truncated` member in the document.
Truncation is silent if you only look at the file. A monthly export of a busy organisation can exceed the cap without any visible sign in the CSV itself. Always check the header or the JSON member, and narrow the date window until the export comes back complete.
A scheduled job should check for truncation and split the window rather than assume a complete pull:
```bash theme={null}
response_headers=$(mktemp)
curl -sS -D "$response_headers" \
-H "Authorization: Bearer " \
"https://platform.ankra.app/org/organisation/audit-logs/export?format=csv&start_date=2026-07-01&end_date=2026-07-31" \
-o audit-log-july.csv
if grep -qi "^x-ankra-export-truncated: true" "$response_headers"; then
echo "Export truncated - narrow the window and re-run" >&2
exit 1
fi
```
***
## Retention, and why you export
Audit entries are retained for **365 days** by default, after which older rows are removed by a background retention job.
If your framework requires a longer trail - and most do, with ISO/IEC 27001 and many SOC 2 programmes expecting multi-year retention - the platform is not your system of record. Export on a schedule into storage you control, with the retention and immutability your policy requires.
A monthly scheduled export into write-once object storage is usually enough to satisfy retention and integrity expectations at once, and it gives you evidence that survives any change to the platform.
***
## Forwarding to a SIEM
The export is a pull interface rather than a push integration, so the pattern is a scheduled job that pulls a window and forwards it.
Issue an [API token](/reference/tokens) for a member whose role grants audit read and nothing else. Do not reuse an administrator's token for automation.
Run daily or hourly with explicit `start_date` and `end_date`, rather than pulling everything each time. Bounded windows keep you under the row cap and make gaps visible.
Fail the job on a truncated response instead of forwarding a partial file.
Ship the rows to your SIEM and keep the raw file in your evidence store. Keep both - the SIEM is for detection, the file is for the assessor.
Run this as a [pipeline agent](/guides/pipeline-agents) or any scheduled runner that can reach the platform API.
***
## What the audit log does not cover
Being clear about the boundary saves you from over-claiming in an audit response.
* **Kubernetes-level activity is not in the audit log.** Actions taken directly against your cluster's API server - by any tool, including `kubectl` through Ankra's proxy - are recorded by your cluster's own Kubernetes audit policy, not by Ankra. Enable Kubernetes audit logging separately if you need that trail.
* **Desired-state changes live in Git.** What changed in a cluster definition, and who committed it, is in your repository's history as attributed commits. The audit log records the platform action, and Git records the content of the change. See [GitOps](/concepts/gitops).
* **Data-plane activity is not recorded.** Ankra is not in your application's request path and has no view of it.
Together the audit export, your Git history and your Kubernetes audit log cover platform actions, configuration changes and cluster API activity respectively. An assessor asking "who changed this cluster" is usually satisfied by the first two.
***
## Related
Read and filter the trail in the platform.
The organisation compliance report and benchmark results.
Grant audit read to a compliance function.
Where this evidence fits in your certification.