Audit trail

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.

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.

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.