---
title: "Audit trail"
description: "Which administrative actions are recorded, how the records are protected from modification, who can read them, and how long they last."
url: "https://cookiebeam.com/docs/compliance/audit-trail"
lang: "en"
---

# Audit trail

Which administrative actions are recorded, how the records are protected from modification, who can read them, and how long they last.

CookieBeam keeps two administrative trails: a team-level activity log covering account and access changes, and a per-banner change log covering edits to banner configuration. Both are separate from consent records, which are covered in [Consent records](https://cookiebeam.com/docs/compliance/consent-records).

## The team activity log

Each entry records the team, the acting user, the action, an optional IP address, a timestamp, and structured metadata. When a write supplies before and after snapshots, the entry embeds a change-set of `field`, `from`, `to` triples that the audit UI renders as `field: from -> to`.

The recorded actions cover authentication and account lifecycle, banner lifecycle, team membership and permissions, single sign-on and directory sync, and API key lifecycle:

- **Access and account** — sign up, sign in, sign out, social login, create team, team switch, transfer ownership.
- **Banners** — create, update, delete, and cookie scans.
- **Team and permissions** — invite, cancel and resend invitations, grant and revoke banner access, bulk banner-access updates, permission changes, preset role application.
- **Single sign-on and provisioning** — connection created and updated, blocked SSO login, directory created and updated, sync received, and user provisioned, updated, deprovisioned or blocked.
- **API keys** — created, rotated, revoked.

### Secrets are redacted

Change-sets pass through a redaction step before storage. Field names are matched case-insensitively as substrings against a pattern list covering passwords, secrets and tokens, so fields such as `secretHeaders`, `apiToken` and `passwordHash` all have their values replaced with a placeholder. The audit trail records **that** a credential field changed, never what it changed to.

### The log is append-only

Rows are protected by a database trigger that blocks modification and deletion outright. Updates are never permitted — there is no re-attribution and no tampering.

Deletion is permitted only for callers that explicitly opt in by setting a purge flag inside their transaction, and exactly two paths do so:

- the scheduled retention job, described below, and
- **full team or account erasure**, which deletes the team's activity log and banner change log along with the rest of its data, as a right-to-erasure request requires.

That second path is the one to remember when you plan around the trail: deleting a team removes its administrative history permanently and immediately, not after the retention window. Export anything you need to keep before erasing a team.

### Who can read it

Viewing and exporting the activity log both require team **administrator** rights. Ordinary members and viewers cannot read it. If your process assumes any team member can review administrative history, that assumption does not hold here.

## The banner change log

Separately, banner edits are recorded per banner with the acting user, an action, the configuration section affected, a human-readable summary and structured metadata. This is the trail to consult when the question is "what changed on this banner, and when" — for example when correlating a change in consent rates with a configuration edit.

## Retention

Both audit stores are purged on a fixed window of **730 days**, or 2 years, by a daily scheduled job.

That window is fixed in code rather than plan-dependent, so it does not vary with your subscription. Consent records are different: their window does vary by plan, and is described in [Retention](https://cookiebeam.com/docs/compliance/retention).

Two safeguards apply to the job:

- It is one of only two paths the append-only trigger permits to delete at all; team erasure is the other, and every other route is blocked.
- The window can be overridden per run for diagnostics, but a destructive run may never shorten it below the policy default — a shorter window is accepted only when the run is a dry run that deletes nothing.

If your own obligations require administrative history for longer than that window, export it before the window closes.