CISA到底在审计什么？真实的IT审计，从来不是对着被审计单位给的流程文档做穿行测试

一、流程的本质是什么？

先弄清楚最基本的问题：流程不是表单，不是节点，不是审批流。

很多审计人员理解的流程，就是销售订单、出库单、发票、凭证。采购就是采购合同、入库单、发票、凭证。然后IT审计就看这些表单在哪个系统里流转，审批节点是谁，有没有关联校验。

这些对不对？对。这些够不够？不够。

这些都只是流程的表面，不是流程的本质。

那流程的本质是什么？流程是一件事从开始到结束的完整链条。这句话的关键词是完整。不是某几个节点的拼接，是端到端的、贯穿所有职能部门的完整链条。

• 销售流程不是销售部门填订单、仓库发货、财务开票。
• 而是客户有需求 → 合同签订 → 发货 → 收款 → 售后的完整闭环。
• 采购流程不是合同、入库、付款。
• 而是需求产生 → 供应商选择 → 采购执行 → 验收入库 → 结算付款的完整链路。

中间任何一个环节断了，流程就是假的。你测到的只是节点，不是流程。

二、真实流程和文档流程，中间差的不是一两点

为什么不能直接拿企业的流程文档来做测试？原因很简单：文档是写出来的，不是跑出来的。

写文档的人可能已经离职了。文档可能更新过但没人通知你。文档描述的是理想状态，实际执行的是现实状态。上一个审计团队留下来的底稿，可能已经是三年前的版本了。

更重要的是，流程节点之间有没有断点，文档上看不出来。

比如一个采购流程，文档上写采购申请 → 部门审批 → 采购下单 → 验收入库 → 付款，每个节点都有人签字。但实际跑起来可能是：

• 采购员先打电话让供应商发货，后补申请单。
• 审批人看都不看就点通过。
• 入库单是财务根据发票倒推的。

这些在流程文档上完全看不出来。但你做测试的时候，如果不验证这些，你的结论就是错的。

三、两套测试逻辑

第一套：对着文档测

找一张单据，走一遍流程节点，看看每个节点的签字、审批、数据校验都合规。文档上有5个节点，你走了5个节点，全部合规，结论：内控有效。

这个逻辑的问题在于：你走的是文档里的流程，不是真实流程。

第二套：挖掘真实流程

先问几个问题：

• 这个流程的起点在哪里？
• 谁发起的？触发条件是什么？
• 流程经过哪些部门？
• 每个节点有没有决策环节？
• 下一个节点的人怎么知道上一个节点完成了？

这些问题的答案，往往不在文档里，而在执行流程的人脑子里。你需要找到真正干活的人，而不是翻文档的人。

审计不是审文档，是审业务。文档只是线索，不是答案。

四、一个真实的例子：废料处理流程

企业给的流程是：仓库发起变卖单 → 称重计量 → 开放行条 → 维护出库单。每个节点都有记录，看起来没问题。

但真实的逻辑是：废料来自原料，原料报废之后才变成废料。那么首先要考虑的就是：

• 谁判断原料变成废料？
• 这个判断有没有记录？什么时候触发？谁审核？

如果对这些问题的判断本身就是随意的，后面的称重、放行、出库单再规范，也改变不了废料管理失控的事实。

再往下，废料有两种处理方式：回收入库或出售。

• 如果是回收入库，财务上应该借记原材料-废料，贷记生产成本。
• 如果不做这一步，生产成本会虚高，利润会偏低。
• 如果这个财务处理本身就是缺失的，流程测再多节点也没用。

这个过程，靠翻流程文档是翻不出来的。需要你去理解业务本身——废料是怎么来的、怎么处理的、怎么入账的，然后把这三段串起来。

五、这些问题的根源是什么？

从上面的例子可以看出，IT审计的难点在于：

需要同时理解技术、业务和财务三个层面，还要能把它们串联成一个完整的逻辑链条。

• 只看系统日志，你看不到业务断点。
• 只看流程文档，你看不到真实执行。
• 只看财务数据，你看不到系统控制。

这就是为什么很多IT审计项目做到最后，只是查了一遍系统有没有日志、权限有没有配置，而不是审了一遍企业真正的业务流程和控制。

说到底，IT审计的核心能力不是会查系统，而是会看业务。

• 你知道流程应该是什么样的，才能判断真实流程有没有问题。
• 你知道端到端链路应该怎么走，才能发现哪个节点断了。
• 你知道业务、系统、财务三者应该怎么对齐，才能发现哪里对不齐。

六、CISA训练的就是这套方法论

CISA全称是国际注册信息系统审计师，由ISACA推出，是IT审计领域最权威的认证之一。

CISA教你建立一套完整的IT审计方法论：

• 怎么从业务起点出发识别风险点
• 怎么找到真实控制点而非文档上的伪控制点
• 怎么设计有效的测试程序
• 怎么把技术、业务、财务三者的逻辑串成一个完整链条

它解决的就是前面提到的那一连串问题：

• 什么流程应该纳入审计范围？
• 怎么识别端到端流程的完整逻辑？
• 怎么判断一个控制点是真正有效还是表面功夫？
• 怎么从发现缺陷走到提出有意义的审计结论？