Audit Log Review¶
Applies to: All subscriptions
Purpose¶
Turn the audit trail from a stored record into an actual control: reviewed on a schedule, by someone who knows what an unexpected entry looks like.
Audience¶
Compliance and internal audit, with the system administrator.
Prerequisites¶
- Audit visibility, which every role holds
- A change log to reconcile against
- Monthly Checks, where this review sits
Reference¶
The audit trail is not the application log¶
| Audit trail | Application log | |
|---|---|---|
| Purpose | Accountability | Diagnosis |
| Audience | Auditors, compliance | Engineers |
| Answers | Who did what, when | Why it failed |
| Accessed through | The application | The log platform |
| Retention | Per the compliance requirement | Operational |
Do not substitute one for the other. An auditor will not accept a log file as evidence of who cancelled a document, and an engineer cannot diagnose a failure from an audit trail.
Verify: The audit trail's retention period and its tamper-evidence properties are not stated in this portal. Confirm before relying on it as audit evidence. Recorded as assumption E4 in the Assumptions Register.
What is recorded¶
| Category | Examples |
|---|---|
| Authentication | Sign-in, sign-out, failures |
| User administration | Creation, role changes, access changes, disabling |
| Configuration | Feature flags, provider assignment, routing rules, policies |
| Document actions | Registration, cancellation, correction, promotion |
| Approvals | Approve, reject, override |
| Data operations | Uploads, exports, deletions |
| Integration | Credential issue and revocation, ingest by machine credential |
Machine actions are attributed to the credential that performed them, which is one reason each ERP should hold its own credential: a shared credential makes an action attributable to "the integration" rather than to a system.
Narrowing to one module¶
Audit actions carry a module prefix — IRN_, EWB_, CEWB_, MV_, IGM_,
GL_, TDS_, PRIVACY_, ERP_, API_ — and the All Modules filter on the
Logs tab selects on it. The filter is applied in the query rather than to the rows
already returned, so it searches the whole history rather than the most recent
page.
Core is the inverse: every action with no module prefix. Logins, user administration and refused access live there, and they disappear the moment you choose any single module. If you are investigating "who changed this user", Core is where it is.
Two modules were added to the audit trail on 2026-08-30 and carry no history before that date:
| Module | What is now recorded |
|---|---|
IGM_ Invoice Generation |
Customer, item and rate masters; invoice create, update, delete and post; credit and debit notes; approve, reject, request cancellation and approval override; numbering series; receivable write-offs |
GL_ General Ledger |
Accounts and journals; posting rules; period close and reopen; year-end close; opening balances; receipts; provisions and bad-debt events |
Before that date these operations happened without an audit entry. Invoice
Generation kept its own narrower trails — a document change log, an approval
request record and a fiscal-period audit — and those remain, but they are not
visible on the Logs tab and never were. Do not read an absence of IGM_ rows
before 2026-08-30 as an absence of activity.
What to look for, monthly¶
Review in this order. It runs from highest to lowest consequence.
| # | Look for | Why it matters |
|---|---|---|
| 1 | Segregation of duties relaxed | Changes who can commit transactions. Must be a recorded decision by the control owner |
| 2 | Cross-tenant access used | Should be rare and justified every time |
| 3 | Feature flags changed | Some change legal behaviour, such as automatic registration |
| 4 | Provider assignment changed | Affects where new documents go |
| 5 | Role changes | Especially anyone gaining transactional authority |
| 6 | New administrators | Should be deliberate and few |
| 7 | Credentials issued or revoked | Each should map to a known integration |
| 8 | Approval overrides | Each should have a business reason |
| 9 | Cancellations | Each should have a reason; a pattern is worth investigating |
| 10 | Deletions and bulk exports | Both are worth a second look |
| 11 | Authentication failures | A spike, or an unusual source |
| 12 | Actions by departed staff | Should be impossible; if present, the leaver process failed |
Reconcile against the change log¶
The review is only meaningful if there is something to compare against. Every control-relevant change should appear in both the audit trail and a change record. An entry in one and not the other is the finding:
| Situation | Meaning |
|---|---|
| In both | Expected |
| In the audit trail, not the change log | An undocumented change. Find out who and why |
| In the change log, not the audit trail | It did not happen, or it happened somewhere else |
Keep attribution intact¶
Attribution survives only if accounts do. Disable departed users; never delete them. A deleted account makes their past actions unattributable, and a compliance system must be able to say who registered a particular document years later.
This is the single most damaging avoidable act in audit terms, and it is usually done with good intentions — tidying up the user list.
Validation¶
| Check | Pass condition |
|---|---|
| The review happened | Logged, with date and reviewer |
| Every control-relevant change reconciled | Present in both the trail and the change log |
| Unexpected entries investigated | Each has an explanation |
| Attribution intact | No deleted accounts; departed users disabled |
| Cross-tenant access justified | Each use has a reason |
| Findings have owners | Each with a name and a date |
Troubleshooting¶
| Symptom | Cause | Action |
|---|---|---|
| A past action cannot be attributed | The account was deleted | Disable, never delete. Attribution may not be recoverable |
| A configuration change nobody recognises | No change log discipline | Establish one. Every control-relevant change gets a record |
| Segregation relaxed with no record | Changed without a decision | Re-enable, then decide properly with the control owner |
| Machine actions attributed vaguely | One credential shared across ERPs | Issue one per ERP |
| The trail is too noisy to review | Reviewing everything rather than control-relevant actions | Use the twelve-item list; it is ordered by consequence |
| Evidence unavailable for an audit period | Retention shorter than the requirement | Confirm retention; extend if necessary |
| The review is skipped when busy | It competes with reactive work | Schedule it as a fixed monthly appointment |
Related Articles¶
- Monthly Checks — where this sits
- Segregation of Duties — the change most worth watching
- User Lifecycle — preserving attribution
- Logs and Observability — the other record