An audit trail is a chronological, attributed record of the actions taken in a system: who did something, what they did, which record it affected, when it happened and what the values were before and after. A good audit trail is append-only. Entries are added, never edited or removed, so the trail can be relied on as evidence.
In accounting, the term also means the chain of documents linking a figure in the accounts back to its source, such as purchase order, invoice and ledger entry. Both meanings share one idea: you can trace any current value back to the event that produced it. An asset audit trail applies this to each asset, from registration to disposal.
What an audit trail entry should record
| Field | What it holds | Example |
|---|---|---|
| Actor | The verified user, device or system process that made the change | J. Mensah; reader Portal-04; integration user “ERP sync” |
| Action | The type of event | Location changed; disposal posted |
| Record | Which object was affected | Asset AST-004217 |
| Before and after | The old and new value of each changed field | Location: Store B → Lab 2 |
| Timestamp | When it happened, in one consistent time zone | 2026-06-03 09:14 UTC |
| Source and context | Where the change came from, plus any reason or reference | Web app; reason “Lab refit”; ref TRF-0091 |
What makes an audit trail trustworthy
- Append-only. Corrections are new entries, not edits to old ones.
- Attributed from sign-in. The actor comes from the authenticated session, not from a name someone types. Shared logins defeat this.
- Complete. Every path that changes data writes an entry: screens, bulk imports, the API and background jobs.
- Tamper-evident. Administrators cannot rewrite it; some systems chain entries with hashes or copy them to write-once storage.
- Retained and searchable. Kept for a written retention period, and filterable by asset, user and date.
Audit trail vs audit log vs history table
| Term | Usually means |
|---|---|
| Audit trail | The full, attributed sequence of events behind a record or transaction, read by auditors and investigators |
| Audit log | The technical log of security and admin events, such as sign-ins and permission changes |
| History table | The per-record list of changes shown in the app, often a “History” tab |
The words overlap in practice. The test is the same: can you show who changed what, when, and what it was before?
Audit trail examples
- Hospital: an infusion pump’s history shows it moved from ICU to Ward 4, went for calibration and came back, which matters in an incident review.
- School: a laptop was issued in good condition and returned damaged; the history settles which loan period the damage happened in.
- Construction: a generator’s trail shows who transferred it between sites and when it left the depot.
Audit trail reports
An audit trail report is a filtered extract of the trail for a purpose: every change to assets at one site in a quarter, every disposal and who posted it, or everything a person changed before they left. Auditors usually want it as a spreadsheet. It often sits alongside an asset audit, which checks the physical items against the register.
Audit trails and compliance
Frameworks such as SOX (internal control over financial reporting) and ISO/IEC 27001 (information security) expect organizations to show who changed important records and to protect logs from tampering. What applies depends on your sector and country; treat this as background, not legal or compliance advice.
Common mistakes
- Logging only the new value, so nobody can see what it was before.
- Letting admins edit or delete history.
Spreadsheet vs software
In Excel or Google Sheets you can approximate a trail with a change-log tab or the file’s version history. But version history belongs to the file, not to each asset, and anyone with edit access can delete rows or save a copy. It breaks down once several people edit or you need one asset’s history over years. Asset software writes an entry on each action, takes the actor from the sign-in and keeps the history with the asset.
Audit trail in Asetavo
Each asset in Asetavo keeps an append-only history of creates, edits, moves, status changes, tag assignments, check-outs and returns, work orders, depreciation postings and disposals, with the old value, the new value, the verified user and the time. Entries are added by the system and are not edited afterwards, and assets with depreciation or disposal records cannot be deleted. API changes are attributed to the integration user. Access is controlled by role-based permissions; see security and audit trail in Asetavo. Register, movement and check-out reports export to Excel or CSV for your auditors.
