IT审计的大部分人都是从IT转换而来，或者IT角度看问题的熟练程度高于财务业务角度。故写此文，与大家一起沟通两者的区别，以便于互转和融会贯通。

　　首先，it审计的概念：通俗的讲，是对it相关系统、 事项进行检查评估，从而判断是否足够支持业务目标。我相信，大部分人都对前半句--“对it相关系统、事项进行检查评估”耳熟能详，也认为这个就是it审 计的实质，实际上，都有些偏了，真正it审计，甚至审计的神韵恰恰在于后半句--“判断是否足够支持业务目标”。如果你弄透了这半句，足够足够了。业务就 是业务，公司、企业设立的目标就一个，赚钱。所以业务至上，所以公司的一切都是围绕着业务转的。这个必须清楚，尤其是在你做it审计过程中，对某些你认为 是风险的 地方耿耿于怀时，一定惦记着这句话，业务至上。有了这个大方向，那很明显，一切的风险都必须以业务风险为最高。举个极端的例子，无论你认为敏捷开发遗留下 的文档有多不规范，只要各个系统上线足够快，与之相关的业务顺利通过该系统进来了，赚钱了。那在老板眼中，这个系统的文档不规范就不是问题，哪怕关键人员离职了，也短期内不是很大的影响。在这种情况下，我们的感悟就是，假如你检查发现有后续长远风险，那请以当前业务收益的影响为主，然后再考虑这个后续长远风险的降低、消除是否对中短期业务有影响，整改是否需要高成本。这个就是业务审计的度，it审计的度。
      其 次，it审计虽说也以业务为主。但绝对不是以无底线为标志。该坚持的原则必须要有。也就是说，在现场也好，在发征求意见稿时也好，都要坚持一个底线原则， 那就是对业务的影响程度。这里就要发挥it技能了，你需要用白话，慢慢告诉你的被审计对象，这个系统，授权存在问题，最明显的影响就是不止你可以审批某批 资金支付，任何一个有该系统权限的人，都可以轻松代替你审批这批资金，而且还可以把金额、账号给改了。方式就是把浏览器中地址信息改一下。。。还有个明显的问题，就是弱密码。尤其是局域网内的应用程序，安全意 识差的用户，再加上密码逻辑弱的系统，问题就来了。这种问题沟通起来，不要直接强硬的说，弱密码，不行。这样根本不是在沟通问题，it、用户也会不服，长 期来看，你的it审计工作不会很顺利的开展起来。建议你这样，弱密码，最严重的风险是什么，能造成什么样的业务风险，这种业务风险越能以金额说明越好，因 为这样一来，it开发人员看到这种很直观的损失金额，会有不同于开发角度的意识产生。同时，这种数字在报告上，也很能让领导们和用户看懂，知晓你的努 力，it审计的努力，还是的确在帮他们规避损失的。仍然拿弱密码说事，在与被审计对象沟通过程中，对于非关键系统，如会议系统，客服系统，弱密码最好作为 提醒，而不入报告，换句话说，这是在送你作为it审计人员的人情。但是对于关键敏感系统，比如资金系统，高敏感权限，比如核心数据查 看、编辑用户，如果出现弱密码，建议你坚持原则，先跟被审计对象沟通下事情严重性，然后晓之以情，告知的确不得不要上报告，因为在你检查到这个弱密码之 前，你根本不知道是否已经由于这个弱密码造成了损失。万一你把一个弥天大错当作人情给送了，倒霉的很明显跑不了我们作为it审计的人员。
      第三，it审计，作为审计来言，是以协助业务目标的实现为最终目的。所以不要平时把自己与被审计对象摆开绝对距离。相反，要在平时跟你的被审计对象打好关系。他们有报告要上报管理层， 甚至外部，你主动提出几条该注意的地方，帮他们把把关，让被审计对象知晓。你作为it审计人员，实际上是以咨询顾问的身份开展你的工作的。只不过在正式检 查时，是以检查者身份出现。平时，最好经常提醒他们那些风险。不要担心实施检查时查不到问题，如果平时提醒到位，他们改了，那查不到问题岂不恰恰是你的工 作已经做得很好了？
      这次说的不是绝对的实务，而是部分需要理解结合实务的，所以也有些很白话，大家凑合看吧。