Audit Log

Every meaningful action inside your organization is recorded in a chain-hashed audit log. The log answers three questions reliably:

1. Who did this?
2. What did they do?
3. When?

It’s designed so that you can detect tampering even by someone with privileged access to the database.

The log lives under Settings → Investigations → Audit Log and requires the audit view permission (admin and auditor roles have it by default).

What’s recorded

The audit log captures every action that changes state in your workspace. A non-exhaustive list:

• Members invited, accepted, deactivated, reactivated.
• Roles assigned and changed.
• Organization settings edited (name, slug, timezone, locale).
• Sign-ins, sign-outs, MFA enrollments, MFA resets.
• Failed sign-in attempts and account lockouts.
• Form templates created, edited, published, retired.
• Classification levels defined or changed.
• Public-session templates created and activated.
• Storage and key configuration changes (where applicable).
• Investigations themselves (someone exporting or viewing the audit log).

Read-only actions are not recorded individually (browsing the members list, opening the org settings page, etc.). The product would generate enormous noise if every page view were logged.

What’s in an entry

Each entry contains:

• A timestamp.
• The actor — the user (or system process) who took the action.
• The action — a short identifier like member.invited, role.changed, form.published.
• A subject — the thing acted on (a member, a template, a setting).
• A reason, if one was required at the time of the action.
• A small metadata payload with the before/after diff or other contextual detail.
• The chain hash (see below).

Sensitive parts of the metadata payload (anything that might contain PII or settings values) are encrypted at rest under your organization’s keyring. Reviewers see the decrypted view in the UI; the database row by itself is not enough to read it.

The tamper-evident chain

Each entry is hashed into the next:

entry-N.chain_hash = SHA256( entry-(N-1).chain_hash  ||  entry-N.content_hash )

In plain English: the audit log is a chain. Each new entry’s hash depends on the previous entry’s hash. If anyone went into the database and modified a row in the middle of the chain — even just to change a timestamp — the hashes of every entry after that point would no longer match.

You can run the chain verification check from the audit log page at any time. The system walks the entire chain and reports either “chain is intact” or “chain is broken between entries X and Y”. A broken chain is a serious finding worth investigating immediately.

Reviewing the log

The audit log page lets you:

• Filter by actor, action category, date range, subject type.
• Search for free text in subjects and reasons.
• Sort by time (newest or oldest first).
• Open any entry to see its full metadata, including the before/after diff for changes.

For investigations of a specific person or a specific subject, filter on that one dimension first and widen from there.

Retention

Two retention policies apply by default:

Retention can be tightened or extended by an install admin in Sovereign. Cloud workspaces use Novantra’s standard retention.

Exporting

Bulk export of the audit log to an external file (CSV, JSON) is not yet available from inside the workspace UI. Reviewers work directly against the page today. Export is on the roadmap; if you have a specific compliance need, talk to your account team about interim options.

What the audit log does not cover

Be aware of the boundary:

• Read access is not individually logged. There is no “this admin opened user X’s profile at this time” record.
• System-internal traffic (scheduled jobs running their normal work) is not in this log. Operational evidence for the install lives separately.
• Public-access participant actions (an external participant filling in a form they were sent) flow into the public-session evidence trail, not the workspace audit log. See Public Access.

Common review scenarios

A few starting points if you’re not sure how to begin:

• “Who invited this user?” Filter on member.invited and the affected email.
• “Why does this user have admin?” Filter on role.changed and the affected user. Each row carries the reason given by the admin who made the change.
• “Was anything changed last weekend?” Filter on the date range. Sort newest first.
• “Has anyone seen / exported sensitive data?” Filter on the audit-view category itself; reviewing the audit log is also audited.

Related

• Members & Invitations — every membership change appears here.
• Roles & Permissions — role changes are audited with the reason captured.
• Public Access — external participant evidence is a separate stream.