Audit Logs: Nobody Reads Them Until They're the Only Evidence

"How did this order end up at 90% off?" "Who deleted this batch of products?" When the boss asks questions like these and the system can only shrug, what follows is a company-wide Rashomon of mutual suspicion. The audit log — the system's record of every significant operation: who, when, did what, changed what into what — exists for exactly this moment. Nobody reads it on a normal day; when something goes wrong, it's the only evidence.

What to Log: Not Everything — Operations With Consequences

The two common extremes: log nothing, or log everything. With the former there's nothing to investigate; with the latter the logs balloon until finding anything is a needle in a haystack. Our principle is to log "operations with consequences" — actions that change money, inventory, permissions, or the existence of data:

• Money: price changes, refunds, discount adjustments, manual edits to order amounts.
• Goods: inventory adjustments, stocktake corrections, edits and voids of inbound/outbound documents.
• Data existence: deleting orders, deleting members, batch imports and exports (exporting the full customer list especially deserves logging — it's the first thing investigated in a data-breach inquiry).
• Permissions: creating accounts, changing roles, resetting passwords. The record of permission changes is itself the starting point of the audit chain.
• Login activity: successful and failed logins, and the source device. Consecutive failures signal an attack; logins at odd hours signal an insider.

Every entry needs at least four elements: who (account), when (precise time), what (action), and the before-and-after values. The last one is the most commonly skipped — but "price changed from 1,200 to 120" and "price was changed" are two entirely different grades of evidence.

The Log Itself Must Be Tamper-Proof, or It's Just a Diary

This is the essential difference between an audit log and ordinary system logs: an audit log must be unchangeable even by administrators. If someone with privileges can delete the record of their own actions after the fact, the log's evidentiary value is zero. Practical measures: logs are append-only — additions only, no edits or deletions; logs are stored separately from the main system, so a compromise of the main system can't touch them; genuinely sensitive environments also replicate logs in real time to an independent service. Our own inventory-management SaaS underpins the payments and stock of franchise stores, and part of the trust between headquarters and franchisees is built precisely on "every adjustment has an undeniable record" — when a reconciliation dispute arises, you open the log, not hostilities.

An audit log doesn't buy surveillance — it buys trust: because everyone knows there's a record, most things that shouldn't happen simply never do.

Retention Policy: How Long, and Who Can Look

How long? It depends on the data's nature. For records tied to transactions and tax, align with the retention period for accounting documents (Taiwan's tax law requires books and records be kept for at least five years). For records of personal-data access, the evidentiary needs of the Personal Data Protection Act argue for keeping more. For purely operational logs, common practice is one year online for fast queries, with older entries compressed and archived to cheap storage. The point is to set the policy before implementing — not delete things haphazardly when the disk fills up.

Who can look also needs design: the log itself contains sensitive information (whose salary was viewed, which customer's data was opened) — so viewing the log should itself leave a record. It sounds like nesting dolls, but in an actual internal investigation, "who went through the records" often matters as much as the records themselves.

When to Build It? As Early as Possible — Retrofitting Is Expensive

Audit logging is the classic "cheap beforehand, expensive afterward" feature: built in at design time, it costs pocket change; retrofitted years after launch, every feature has to be revisited — and the blank period before the incident can never be recovered. It pairs with permission design — permissions decide who can open the door, logs record who opened it, and only together do they make complete internal controls. If your system today can't even answer "who changed the price," put this into your next release — don't wait for the day you need evidence to discover a blank page. For how to retrofit these controls and prioritize them, see our custom systems and SaaS services.