1、IT审计思想方面。
说到思想，可能会让很多人打哈欠。其实真正会讲这些东西的人，能分析的如醍醐灌顶，可惜咱口拙。
单从审计角度出发，审计可以笼统说成就是针对某条业务流程，检查是否有恰当的内部控制措施能实现保证这个流程按照或接近理想的想法顺顺当当走完。
IT审计的应用控制检查也一样，针对各个系统中某条数据流或业务流，从输入，到内部处理，到输出，检查是否都有足够的内部控制保证维持它顺利按照既定路线走完，就是这个思想的核心了。
至于发现了某个节点出现了重大内控风险点以后，到底怎么对待，怎么沟通，那是之后的事情了。
2、IT审计流程方面。
我发现大部分IT审计的书籍课件都只是重点描述检查哪些风险点，而对于怎么开始着手从接项目到入手检查这中间一段，详细探讨的甚少，我就根据自己的经验抛砖引玉一次。不只是涉及到应用控制，对整个IT审计项目流程都适用。
应用控制怎么查，领导某天说，小某某，我们对XXX系统做个项目吧，你能做吗？肯定耳闻拍胸脯啪啪响。
顶着这么简单的一条指令，回头肯定要做那么复杂的一堆事情。
首先，我们得理清思路，为啥做这个项目。领导想得到的结果是什么：确认资金系统是否有漏洞？确认核心系统是否业务能够正常来往？还是对接下来要改造的目标系统摸摸是否值得继续投资的底？这个是搞IT审计的第一条，了解要开战的重点。除了领导需求之外，还有几条，比如这个系统你已知它有问题的地方（比如太多人抱怨哪个环节总报错，卡死）、这个系统据你判断可能出问题的地方（比如与外部系统接口处的逻辑判断），还有这个系统本身最重点功能的地方（比如资金系统的支付逻辑判断、审批流判断）。
其次，我们在知道要做啥的前提下，收集阅读详细需求开发文档、运维变更文档、数据结构、业务及逻辑流程图、拓扑图、用户说明书、生产环境前台账号、最好还有测试系统的各个环节账号以及测试系统的后台数据库权限，以方便穿行测试以及白盒测试。这些拿到，开始最痛苦的了解系统。这一环节需要把前台实际操作、后台数据逻辑、所涉及业务实务掰碎揉合。
第三，把目标系统功能大卸八块。按照各个功能模块细细的洗了拆开，分放在excel的每一行。有各种功能混杂在一个模块同时实现的也表明细分。这样的好处是方便设计风险矩阵。
第四，开始设计风险矩阵，简单说就是在了解以上各条的前提下，在业务重点、风险大小、风险可能性等方面对拆开的各个功能块打分，最终会拿到一份这次要重点检查哪块的矩阵图。
第五，根据矩阵，开工。
如果有时间，最好再设计一份详细的每个要检查的模块所涉及的风险点。然后按照风险点一个个检查。
接下来就需要用到审计知识了。比如要检查某个审批流的内控设立、执行情况。首先得看下是否设置了审批流，从用户说明书、概要设计上看这条审批流是否完整、满足业务需求。用以判断是否业务逻辑本身有问题。然后我们需要查看系统中所开发内置的审批流功能的实现是否与详细需求文档一致。用以判断系统内的控制是否与设计一致。这时就看到有后台数据库权限的好处了，前台边输入数据、处理、输出数据进行操作，后台则每一步都查看分析数据。最后我们检查生产环境下用户根据审批流的功能所配置的具体业务审批数据是否足以满足之前需求文档中理想的业务需要。穿行测试、符合性测试、白盒、黑盒都可以用。