← Back to Concept Contrast

Concept Contrast Fable

Auditability and audit evidence: one is the structure that lets people inspect the system, the other is the slip of paper found during inspection

Conclusion first:Auditability refers to a system's design itself—log structure, recording strategy, data retention and query capability—and whether it supports independent review. Audit evidence is the specific records, logs and documents collected after an audit is performed. Poor auditability means the system simply cannot produce evidence; no audit evidence means a particular audit did not find what it was looking for—these two things have different causes.

Auditability refers to a system's design itself—log structure, recording strategy, data retention and query capability—and whether it supports independent review. Audit evidence is the specific records, logs and documents collected after an audit is performed. Poor auditability means the system simply cannot produce evidence; no audit evidence means a particular audit did not find what it was looking for—these two things have different causes.

Fable

The accountant had two people to check: one to check whether the ledgers could be browsed at will, and one to check whether there had been false accounts in previous years

The Yangzhou salt merchants' guild audited its accounts every twelfth lunar month. The inspector went through the ledgers of twelve branches and found that some branches could explain in half a day where a salt certificate came from, to whom it was sold, and when the silver entered the vault; other branches searched until dark and found only a few sheets of rough-edged paper, with half the dates missing and the handler recorded as just a surname.

He initially assumed the latter must be skimming more. It took him half a year of investigation to understand that the problem was not first about whether they skimmed, but about whether it could be investigated at all. Some branches had stipulated from the day they opened: every transaction must record the date, amount, handler's seal and counterparty name; the general ledger must be reconciled every seven days; old ledgers must be sealed with lead and sent to the central vault for storage. Even when such a shop made mistakes, it left a thread to follow.

A bad ledger had none of these rules. Today's entry went on a wooden plaque, tomorrow's on loose paper; when silver went missing from the counter, the accountant said the clerk forgot to write it down, and the clerk said the manager gave a verbal order. The more the inspector investigated, the more it felt like groping along a wall in fog—he would touch a trace and still not know where it came from.

The head office therefore split auditing into two things. In July, it first checked the “accounting method”: whether the ledger grid was fixed, whether seals were complete, how many years vouchers were kept, who could open the lead seal, and whether supplementary entries had to preserve traces of the old ones. At this point it did not chase any particular sum of silver; it only looked at whether the shop had left a path for future audits.

In the twelfth month they checked the "accounts" again: they pulled out specific salt certificates, silver notes, signatures, and correspondence. For example, on the eighteenth day of the third month, the eastern shop under-recorded a salt certificate by twenty dan, which led to two contract sheets with inconsistent prices; this was the evidence found that year.

The inspector later often reminded newcomers: in July you inspect the roads; in December you pick up the footprints left on the roads. Without roads, footprints scatter in the mud and no one can explain them clearly; with roads, footprints may be found, preserved, and brought to the hall to speak.

Later a new inspector wanted to close a case using only a twelfth-month voucher. The old inspector stopped him: first look at where this voucher came from. If the ledger normally has no signatures or seals and old volumes can be altered at will, then no matter how proper the paper dug up today looks, it may have been written after the fact. Conversely, no matter how strict the accounting rules are, if this time no salt permit, silver note, and signature or seal were obtained, one cannot say a certain entry is correct just because the system is clean. Only when the two things are combined can the review stand firm. Later the general office also wrote the two kinds of checks into different files. The accounting-rules file could be used long term, while the accounts file corresponded only to a certain year and month. When a newcomer picked up the wrong file, the old inspector made him recheck it.

Auditability

Structural properties built into a system or process when it is designed to support independent review, including record completeness, immutability, traceability, and retention policy. It answers the question "can this system withstand an audit by design?"

Audit evidence

Records, logs, documents, or other verifiable pieces of information collected during a specific audit process. It is the product of auditability plus actual audit operations, and answers the question "what did this audit find?"

Story Mapping

  • The problems found across the twelve branches were unevenly distributed: not because the degree of embezzlement differed, but because the quality of the bookkeeping systems differed
  • The Three Great Disciplines of a Good Branch: Three Design Properties of Auditability—Complete Records, Regular Reconciliation, and Tamper-Resistant Storage
  • The inspector searches the bottom to verify system quality: proactively checking auditability rather than passively waiting for evidence
  • Anomalous salt certificate trading records at the Yangzhou East Office: a specific piece of audit evidence
  • Two prerequisites for evidence to exist: institutional rules (auditability) and execution records (evidence generation)
  • Two-tier audit process for the guild: July institutional review (auditability check) → December accounts review (evidence collection)
  • The tragedy of ERROR ONLY logs: a typical system design anti-pattern with high availability but zero auditability

Applied to system audit capability design and compliance review preparation

Before taking on a client audit, don't wait until the audit notice arrives to start digging through logs—do a self-check first to judge the system's auditability. Checklist: Do log levels cover all key operations? Do logs have tamper-proof mechanisms? Are key fields (user ID, operation type, timestamp, source IP, target resource) all present in the log schema? Does the retention period meet compliance and contractual requirements? Auditability is a design task before the system goes live, not an emergency task before an audit. If auditability is ignored at the architecture stage, the cost of adding it later is usually building a whole separate bypass audit system—time and budget start at five times the original plan.

京ICP备2026014272号