寓言
账房有两个人要查，一个查账册是不是随便能翻，一个查往年有没有假账
扬州盐商总会下辖十二家分号，每年腊月由总会的稽查老爷带队查账。稽查老爷上任三年后发现一件怪事：有一半的分号查出来的问题都差不多——账册不全、记录缺日期、银钱往来没有批注——但另一半分号查出来的问题五花八门，什么都可能有。他花了半年时间调查原因，得出一个结论：不是分号的人贪墨程度不同，是分号的记账制度质量不同。
他把十二家分号的记账制度做了摸底。好的分号有三大纪律：每笔进出必须有日期和经办人章、每七天汇总一次对账、账册锁在带铅封的铁柜里定期移送总会。差的分号根本没有制度——今天记在毛边纸上，明天记在木牍上，经手人只有一个潦草的姓。稽查老爷的结论是：差的那些分号不是查不出问题，是根本没东西可查。
可审计性描述的就是那三大纪律。它不等同于审计本身，也不等同于审计结果，关键在于系统是否被设计成「能经得起独立审查」。有日期、有签章、有按期的对账记录——这些是系统的设计属性。没有这些属性，你把全世界最好的审计师叫来也查不出结果，因为系统没有给他留下足够的痕迹。
审计证据是每次审计后采集到的具体内容。这一年稽查老爷查了扬州东号，翻出了去年三月一笔数额对不上的盐引交易——这就是一条审计证据。这条证据的存在依赖两个前提：东号的记账制度（可审计性）规定每条盐引交易必须记录交易双方、数量、日期和价格。东号的账房实际执行了这条规定，留下了可以核查的痕迹。
盐商总会后来把稽查流程分了两层。第一层每年七月份做「制度审」——不翻账本，只检查各分号的记账制度是否就绪：记录规范、保存期限、经手人追溯、凭证防篡改。这一层审的是可审计性。第二层腊月做「账目审」——翻账本、找异常、追流向，生成的稽查报告就是当年的审计证据。如果七月份发现某家分号的制度就绪度为低，稽查老爷会提前预警：腊月你去查这家，很可能得不到充分的审计证据。
在技术系统里，可审计性和审计证据的关系一模一样。可审计性决定了你能不能配置好日志级别、事件 schema 是否包含审计字段、日志是否不可篡改、保留期够不够覆盖合规要求。审计证据是实际查询日志后得到的那一串具体记录——某用户在某时间执行了某操作，来源 IP 是某地址。
一个典型反例：系统上线时为了节省存储把日志级别设成 ERROR ONLY，两年后客户要求提供访问记录的审计证据。运维团队查出来的结果是零——不是因为不存在访问，是因为 DEBUG 和 INFO 级别的访问记录根本没被写入日志。这不是审计证据缺失，是系统在设计时就没有考虑可审计性——可用性很高，可审性为零。