← 返回概念辨析

Concept Contrast Fable

可审计性和审计证据,一个是系统让人查的结构,一个是查出来的那张纸条

可审计性是指一个系统的设计本身——日志结构、记录策略、数据保留和查询能力——是否支撑独立审查。审计证据是执行一次审计后采集到的具体记录、日志和文档。可审计性差意味着系统根本产不出证据;没有审计证据意味着某次审计没有找到想要的东西——这两件事病因不同。

寓言

账房有两个人要查,一个查账册是不是随便能翻,一个查往年有没有假账

扬州盐商总会每年腊月查账。稽查老爷翻十二家分号的账册,发现有的分号半天就能说清一笔盐引从谁手里来、卖给谁、银子何时入柜;有的分号翻到天黑,只找到几张毛边纸,日期缺一半,经手人只写了个姓。

他起初以为后者一定贪得更多。查了半年才明白,问题先不在贪不贪,而在能不能查。有的分号从开张那天起就规定:每笔进出必须写日期、数额、经办人章和对方名号;每七日对一次总账;旧册铅封后送总会库房保存。这样的铺子即使出错,也会留下线头。

差的分号没有这些规矩。今日记在木牌,明日记在散纸;柜上少了银子,账房说是伙计忘写,伙计说是掌柜口头吩咐。稽查老爷越查越像在雾里摸墙,摸到一处痕迹,也不知道它从哪里来。

总会于是把查账分成两件事。七月先查“账法”:账册格子是否固定,印章是否齐,凭证保存几年,铅封谁能开,补记要不要留旧痕。这时不追某一笔银子,只看铺子有没有给以后查账留下路。

腊月再查“账目”:翻出具体盐引、银票、签章和往来书信。比如东号三月十八日一笔盐引少记二十担,牵出两张价格不一致的契纸,这才是当年查到的凭据。

稽查老爷后来常提醒新人:七月查的是路,腊月捡的是路上留下的脚印。没有路,脚印散在泥里,谁来也说不清;有路,脚印才可能被找到、保存、带到堂上说话。

后来一位新稽查只拿着腊月凭据就想定案,老稽查拦住他:先看这张凭据从哪里来。若账册平日无人签章,旧册随便可改,今日翻出的纸再像样,也可能只是事后补写。反过来,账法再严,若这次没有取到盐引、银票和签章,也不能凭制度清白就说某笔无误。两件事合在一起,审查才站得稳。后来总会还把两种检查写成不同卷宗。账法卷可长期沿用,账目卷只对应某年某月。新人拿错卷宗时,老稽查便让他重查一遍。

可审计性

系统或流程在被设计时内置的支持独立审查的结构属性,包括记录完整性、不可篡改性、可追溯性和保留策略。回答「这个系统从设计上能不能经得起审计」的问题。

审计证据

在具体的一次审计过程中采集到的记录、日志、文档或其他可验证的信息片段。它是可审计性加上实际审计操作后的产物,回答「这次审计查到了什么」的问题。

故事对应

  • 十二家分号查出的问题分布不均:不是贪墨程度不同,是记账制度质量不同
  • 好分号的三大纪律:可审计性的三个设计属性——完整记录、定期对账、防篡改存储
  • 稽查老爷搜底验制度质量:主动检查可审计性而非被动等证据
  • 扬州东号的盐引交易异常记录:一条具体的审计证据
  • 证据存在的两个前提:制度规定(可审计性)和执行记录(证据产生)
  • 总会两层稽查流程:七月制度审(可审计性检查)→ 腊月账目审(证据采集)
  • ERROR ONLY 日志的悲剧:可用性高但可审性为零的典型系统设计反例

落到系统审计能力设计和合规审查准备

接客户审计前不要等到审计通知来了才开始翻日志——先做一次自查判断系统的可审计性。检查清单:日志级别是否覆盖了所有关键操作?日志是否有防篡改机制?关键字段(用户 ID、操作类型、时间戳、来源 IP、目标资源)是否都出现在日志 schema 里?保留期是否满足合规和合同要求?可审计性是系统上线前的设计任务,不是审计前的应急任务。如果可审计性在架构阶段被忽略,后面补的成本通常是新建一套旁路审计系统——时间和预算都是原方案的五倍起。