Audit log

Audit log

The audit log captures every modification to every audited record in the platform. Every save, every status change, every role assignment, every SCR check edit. With timestamps, the user who made the change, and the before/after values.

This is the document you point inspectors at when they want to verify “what was this on this date?” or “who changed this?”.

What’s audited

By default:

• Tickets, changes, problems, projects (every field change)
• People records (especially staff + pupil safeguarding-relevant fields)
• SCR records (every check, every renewal)
• Risk register entries
• Policies (every version change)
• Compliance controls
• Approval decisions
• User role + department assignments
• Workspace settings changes
• Branding changes
• SSO config changes
• Mail config changes

Read access to sensitive records (who viewed an SCR/DBS safeguarding record, full staff PII, or the audit/DSAR consoles) is recorded in a separate Access log — see Admin → System → Access log. It is tamper-evident in the same way and has its own retention window.

What isn’t audited:

• Ordinary read access to non-sensitive records, and search queries
• View customisations (your saved filters)
• KB hit counters

Reading an entry

Each audit row shows:

• When — ISO timestamp + relative (“3 hours ago”)
• Who — user (deactivated users still attribute)
• Where — which model + record id
• Action — created / updated / deleted
• Changes — JSON-shaped before/after for the modified fields
• Source — UI / API / CLI / system event

Click any row for the full diff view.

Filtering

The audit index has heavy filters:

• Time range — last hour, today, this week, custom
• User — single user
• Model type — Tickets, SCR records, etc.
• Action — create / update / delete
• Field — only changes to a specific field
• Workspace — for platform admins; cross-workspace filtering

Useful patterns:

• “Show me everything {{user}} did in the last 24 hours” — for incident response
• “Show me every change to SCR records in the last week” — for safeguarding leads
• “Show me all approval decisions in the last month” — for finance audit

Retention

Audit entries are kept indefinitely by default. A platform admin can set a retention period (e.g. 7 years for SCR audits, 2 years for tickets) — entries older than the cutoff are archived to cold storage and pruned from the live index. Archived entries can be restored on request.

Don’t shorten retention casually. The whole point of the audit log is that it’s there when you need it years later.

Read-only

The audit log is read-only through the UI and the API. No user, regardless of role, can edit or delete audit entries. The platform admin can configure retention but can’t surgically remove a row.

This is deliberate. An audit log you can edit isn’t an audit log.

Export

Filtered audit views export to CSV / JSON / PDF for inclusion in investigation packs or inspection submissions. The export records who exported what when (audited audit access — yes, really).