Skip to main content

Use the audit log

The audit log records every action that touches data — who did it, what changed, and when. Use it to investigate a change, answer "who viewed this person's record", or hand an auditor a filtered export.

The page lives at Admin → Audit log in the sidebar. It is read-only: you can filter and export the trail, but you can't edit or delete an entry from the UI.

:::note Before you begin

  • You need an admin role — admin, it-admin, or super-admin. The audit log isn't visible in the My portal.
  • Your workspace must have an active subscription. If your workspace restricts the admin console to specific IP addresses, you must be on an allowed address to reach the page.
  • Entries are written automatically as people work. There is nothing to turn on. :::

What each entry records

Every row is one action against one record. The table shows five columns; expand a row to see the raw change.

ColumnWhat it showsNotes
WhenDate, time, and a relative age ("2 hours ago")Stored in UTC; the relative age is computed from now
DescriptionA human-readable summary of the actionThis is the field the Search box matches
SubjectThe record that changed — its type and ID, for example Hardware #142Blank () for actions with no single target, such as an export
ActorThe person who did it, by name and emailShows a System badge for automated actions with no signed-in user
EventThe kind of change, as a coloured badgeSee the event types below

Where the action carried extra detail — the before-and-after values of an edit, or the filters used for an export — a Details button appears at the end of the row. Select it to expand the raw change as formatted JSON.

Event types

The Event badge is colour-coded so you can scan a page at a glance.

EventBadge colourMeaning
createdEmeraldA record was created
updatedSkyA record was changed
deletedRoseA record was removed
OtherSlateAny other recorded action, such as an export or a state transition
note

Actions taken by a scheduled job or the system itself — for example the nightly retention prune — show the System badge in the Actor column because no person was signed in. That's expected, not a gap.

Filter the trail

Filters live in the bar above the table. Each one narrows the list and is preserved in the page URL, so you can bookmark or share a filtered view. The entry count under the bar updates as you filter.

FilterMatchesBehaviour
SearchThe Description textSubstring match — typing assigned finds every "... assigned ..." entry
EventThe event typeChoose one of the event types present in your data, such as created or deleted
SubjectThe log channel the entry belongs toGroups entries by area, for example hardware, auth, or security
FromEntries on or after a datePick a date; combine with To for a range
ToEntries on or before a datePick a date; combine with From for a range

To narrow the list:

  1. Type in Search, or open the Event or Subject dropdown and pick a value. The list reloads as soon as you change a dropdown or a date.
  2. Set From and To to bound a date range.
  3. Select Clear to drop every filter and return to the full trail. The link appears only while a filter is active.
tip

The Subject dropdown lists the log channels actually present in your data, so it doubles as a map of what's being recorded — for example auth for sign-in events, security for SSO and SCIM role changes, compliance for evidence and effectiveness actions, and pii-read for record-view access (see below).

Read-access entries

Most entries record a change. The platform also records reads of individual personal-data records, so you can answer "who viewed this user's record last month" — a question SOC 2 CC6.1 and NIS2 Article 21(2)(j) both expect you to answer.

These entries appear under the pii-read subject with a description such as pii.read.user or pii.read.hardware. Expand the row to see the viewer's email, IP address, and the page they opened. The platform logs the detail page for a user or a piece of hardware; it does not log list pages or dashboards, because those show aggregate counts rather than one person's data.

Export the trail

Export streams the current view — with the same filters applied — to a file you can attach to an evidence request or load into a spreadsheet. Set the filters first, then export, so the file contains exactly what's on screen.

To export:

  1. Apply the filters you want the file to contain.
  2. In the page header, select Export CSV for a spreadsheet-ready file, or Export JSON for the structured form.

The file downloads as audit-log-<timestamp>.csv or audit-log-<timestamp>.json, named with the moment you generated it.

FormatBest forContents
CSVSpreadsheets and auditor hand-offOne row per entry, with a UTF-8 byte-order mark so Excel reads accented names correctly
JSONImporting into another tool or a SIEMAn entries array plus an exported_at timestamp; each entry nests its actor, subject, and full properties

Both formats include the entry ID, timestamp, log channel, event, description, the actor's email and ID, the subject's type and ID, and the full change properties.

note

The export is itself an auditable action. Each download writes an entry reading Audit log export downloaded under your name, recording the format and the filters you used — so the act of pulling the log is part of the log.

Retention and integrity

Audit entries are immutable: nothing in the product edits or deletes an individual entry. A nightly job trims entries older than your retention window so the table doesn't grow without bound.

PropertyDefaultHow to change it
Retention window365 daysRaise it for a longer compliance window
Minimum window30 daysA hard floor — the prune refuses to run below 30 days
Long-term archiveOffStream entries to your own log store before they're pruned

The prune runs automatically at 03:00 each day and records its own entry — how many rows it removed and the cutoff date — so the trail shows that retention ran. To keep entries beyond your retention window for a longer compliance regime, raise the window or stream to an external store rather than relying on the in-product table.

warning

Personal data inside an entry is pseudonymised — not deleted — when you erase a user under GDPR, so the action trail stays intact while the person's identity is removed. The audit history survives a "right to be forgotten" request; see GDPR and DSAR for how erasure works.

Which frameworks this evidences

A single export answers several audit questions at once, which is why the trail underpins the evidence packs rather than mapping to one framework.

FrameworkControlWhat the log proves
SOC 2CC7.2A monitored activity trail exists and is reviewable
ISO/IEC 27001Annex A 8.15Logging of user and system activity
NIS2Article 21(2)(j)Access-control and incident-response evidence, including read access
GDPRArticle 30A record of processing activity for subject-access requests

Troubleshooting

SymptomWhat to do
The page won't loadThe audit log needs an admin role and an active subscription. If your workspace uses an IP allowlist, confirm you're on an allowed address.
An export button does nothingThe file streams as a download. Check your browser's download tray or pop-up settings, then select the button again.
The export has fewer rows than expectedThe export honours the current filters. Select Clear to drop all filters before exporting the full trail.
Accented names look garbled in ExcelOpen the CSV with UTF-8 encoding. The file includes a byte-order mark, so a current Excel reads it correctly on open rather than via raw paste.
An entry shows System as the actorThe action came from a scheduled job or the platform, not a signed-in person. This is expected for automated tasks like the retention prune.
Old entries are missingThe nightly prune removes entries past your retention window. Raise the window, or stream to an external store, to keep them longer.