Data Retention and the Audit Trail

Two kinds of data, two retention rules

Zenmanage keeps two categorically different kinds of records, and they're governed by opposite policies. The governance audit trail — every configuration write, permission change, and target publish — is your compliance record, and it is kept indefinitely. Operational telemetry — API request logs, webhook delivery payloads, evaluation usage data, per-environment retrieval records — exists to support debugging and reporting, and each of those tables is pruned on its own documented schedule.

The Audit History Guide already covers what an audit entry looks like, how before/after diffs work, and how to use filters to investigate an incident — this page doesn't repeat any of that. What follows is the part that guide doesn't answer: how wide the action catalog actually is, how the per-flag history view is assembled, what compliance export supports, and exactly how long each kind of data sticks around.

The action catalog is wider than flag changes

It's easy to assume the audit trail only logs flag and target changes. In practice it records over thirty distinct action types, grouped into a few areas:

Reads and lists are logged alongside writes on purpose. A compliance review that only sees who changed a flag is missing half the picture — who looked at production targeting rules, or pulled the account's full audit export, is exactly the kind of access question this trail is built to answer.

A flag's full history includes its targets

When you filter the audit log to a single flag, you're not only seeing direct edits to that flag record. The filter also pulls in every target-publish event scoped to that flag — publishing a target, rolling it back, or changing its rollout percentage — merged into one chronological result with the flag's own creates, updates, and deletes.

Exporting for compliance

The audit log can be exported as CSV directly from the account or project-level view, for inclusion in post-mortems or compliance documentation. Export has two constraints worth knowing before you request one:

• An explicit date range is required. There is no "export everything" option — you must supply both a start and end date, so every export is scoped to a specific review period rather than the entire account history.
• A single export can cover at most 180 days. Requesting a longer range fails validation. For a review period beyond six months, request it as sequential exports rather than one wide one.

The governance audit trail is never pruned

Every entry described above — flag and target changes, project and environment changes, webhook config changes, team and grant changes — lives in the same append-only, immutable table, and nothing deletes rows from it on a schedule. It is retained for the lifetime of your account. That's a deliberate design choice: a governance record that could silently age out would undermine the reason it exists.

The tables below are different. They hold high-volume operational telemetry — not governance events — and each is pruned automatically once it ages past its retention window.

If you rely on any of these for your own long-term reporting, export or mirror the data before it ages out of its window — none of them can be recovered once pruned.

Where to go next

For step-by-step investigation, release-timeline reconstruction, and compliance review workflows built on top of the audit trail, see the Audit History Guide. To scope who can read the audit trail without granting write access, see the Scoped Permissions Setup Guide. For the platform's broader data-handling posture, see Security and Data Handling. For the full feature overview, see the Permissions & Audit capability page.