Understanding audit trails and proof of compliance

The audit log records the history of every request: who made each change, what changed, and when. It is designed to be the record you cite when the handling of a request is questioned.

What makes it citable

Entries are written as part of the action. An action either succeeds and is recorded, or it does not happen. There is no path by which something completes without its record.

Entries are append-only. An error is corrected by a later entry stating the correction, never by altering the original.

Entries are cryptographically chained. Each is linked to the one before it, so alteration from outside the product is detectable.

A record that can be quietly rewritten has no evidentiary value in the one moment it exists for. That is why none of this is configurable.

What it is not

The audit log is not an activity feed and not a diagnostic tool. Application logs and error reporting are separate systems that deliberately contain no personal information and do not constitute a record.

To establish what a person did, use the audit log. For questions about application performance, look elsewhere.

Where to read it

Per request, open the request and go to Activity Log. That is the chronological trail for that one request, which is what you need most of the time.

Agency-wide, go to Settings, then Records & Compliance, then Audit Logs.

Retention

Audit entries are kept beyond the life of the requests they describe. Deleting a request does not remove the record of its existence and its handling.

A disposal that erased its own evidence would defeat the purpose of keeping the record.

What this gives you in practice

When you are asked how a particular document was handled two years afterwards, the answer is not a recollection or an email chain. It is a log showing what was proposed, what a person decided, who they were, and when.

That is also why writing internal notes matters. The log records what happened. A note records why, and only a person can supply that.