一、审计计划阶段#
计划阶段是整个审计过程的起点。其主要工作包括:
(1)了解被审系统基本情况#
了解被审系统基本情况是实施任何信息系统审计的必经程序,对基本情况的了解有助于审计组织对系统的组成、环境、运行年限、控制等有初步印象,以决定是否对该系统进行审计,明确审计的难度,所需时间以及人员配备情况等。
了解了基本情况,审计组织就可以大致判断系统的复杂性、管理层对审计的态度、内部控制的状况、以前审计的状况、审计难点与重点,以决定是否对其进行审计。
(2)初步评价被审单位系统的内部控制及外部控制#
传统的内部控制制度是为防止舞弊和差错而形成的以内部稽核和相互牵制为核心的工作制度。随着信息技术特别网络技术的发展和应用,企业信息系统进一步向深层次发展,这些变革无疑给企业带来了巨大的效益,但同时也给内部控制带来了新的问题和挑战。加强内部控制制度是信息系统安全可靠运行的有力保证。依据控制对象的范围和环境,信息系统内控制度的审计内容包括一般控制和应用控制两类。
一般控制是系统运行环境方而的控制,指对信息系统构成要素(人、机器、文件)的控制。它已为应用程序的正常运行提供外围保障,影响到计算机应用的成败及应用控制的强弱。主要包括:组织控制、操作控制、硬件及系统软件控制和系统安全控制。
应用控制是对信息系统中具体的数据处理活动所进行的控制,是具体的应用系统中用来预测、检测和更正错误和处置不法行为的控制措施,信息系统的应用控制主要体现在输入控制、处理控制和输出控制。应用控制具有特殊性,不同的应用系统有着不同的处理方式和处理环节,因而有着不同的控制问题和不同的控制要求,但是一般可把它划分为:输入控制、处理控制和输出控制。
通过对信息系统组织机构控制,系统开发与维护控制,安全性控制,硬件、软件资源控制,输入控制,处理控制,输出控制等方而的审计分析,建立内部控制强弱评价的指标系统及评价模型,审计人员通过交互式人机对话,输入各评价指标的评分,内控制审计评价系统则可以进行多级综合审计评价。通过内控制度的审计,实现对系统的预防性控制,检测性控制和纠正性控制。
(3)识别重要性#
为了有效实现审计目标,合理使用审计资源,在制定审计计划时,信息系统审计人员应对系统重要性进行适当评估。对重要性的评估一般需要运用专业判断。考虑重要性水平时要根据审计人员的职业判断或公用标准,系统的服务对象及业务性质,内控的初评结果。重要性的判断离不开特定环境,审计人员必须根据具体的信息系统环境确定重要性。重要性具有数量和质量两个方面的特征。越是重要的子系统,就越需要获取充分的审计证据,以支持审计结论或意见。
(4)编制审计计划#
经过以上程序,为编制审计计划提供了良好准备,审计人员就可以据以编制总体及具体审计计划。
总体计划包括:被审单位基本情况;审计目的、审计范围及策略;重要问题及重要审计领域;工作进度及时间;审计小组成员分工;重要性确定及风险评估等。
具体计划包括:具体审计目标;审计程序;执行人员及时间限制等。
二、审计实施阶段#
做好上诉材料的充分的准备,便可进行审计实施,具体包括以下内容:
(1)对信息系统计划开发阶段的审计#
对信息系统计划开发阶段的审计包括对计划的审计和对开发的审计,可以采用事中审计,也可以是事后审计。比较而言事中审计更有意义,审计结果的得出利于故障、问题的及早发现,利于调整计划,利于开发顺序的改进。
信息系统计划阶段的关键控制点有:计划是否有明确的目的,计划中是否明确描述了系统的效果,是否明确了系统开发的组织,对整体计划进程是否正确预计,计划能否随经营环境改变而及时修正,计划是否制定有可行性报告,关于计划的过程和结果是否有文档记录等等。
系统开发阶段包括系统分析、系统设计、代码编写和系统测试三部分。其中涉及包括功能需求分析、业务数据分析、总体框架设计、结构设计、代码设计、数据库设计、输入输出设计、处理流程及模块功能的设计。编程时依据系统设计阶段的设计图及数据库结构和编码设计,用计算机程序语言来实现系统的过程。测试包括动态测试和静态测试,是系统开发完毕,进入试运行之前的必经程序。
其关键控制点有:分析控制点:是否己细致分析企业组织结构;是否确定用户功能和性能需求;是否确定用户的数据需求等。
设计控制点:设计界面是否方便用户使用;设计是否与业务内容相符;性能能否满足需要,是否考虑故障对策和安全保护等。
编程控制点:是否有程序说明书,并按照说明书进行编写;编程与设计是否相符,有无违背编程原则;程序作者是否进行自测;是否有程序作者之外的第三人进行测试;编程的书写、变量的命名等是否规范。
测试控制点:测试数据的选取是否按计划及需要进行,是否具有代表性;测试是否站在公正客观的立场进行,是否有用户参与测试;测试结果是否正确记录等。
(2)对信息系统运行维护阶段的审计#
对信息系统运行维护阶段的审计又细分为对运行阶段的审计和对维护阶段的审计。系统运行过程的审计是在信息系统正式运行阶段,针对信息系统是否被正确操作和是否有效地运行,从而真正实现信息系统的开发目标、满足用户需求而进行的审计。对信息系统运行过程的审计分为系统输入审计、通信系统审计、处理过程审计、数据库审计、系统输出审计和运行管理审计六大部分。
输入审计的关键控制点有:是否制定并遵守输入管理规则,是否有数据生成顺序、处理等的防错、保护措施、防错、保护措施是否有效等。
通信系统实施的是实际数据的传输,通信系统中,审计轨迹应记录输入的数据、传送的数据和工作的通信系统。通信系统审计的关键控制点有:是否制定并遵守通信规则,对网络存取控制及监控是否有效等。
处理过程指处理器在接收到输入的数据后对数据进行加工处理的过程,此时的审计主要针对数据输入系统后是否被正确处理。关键控制点有:被处理的数据,数据处理器,数据处理时间,数据处理后的结果,数据处理实现的目的,系统处理的差错率,平均无故障时间,可恢复性和平均恢复时间等。
数据库审计是保障数据库正确行使了其职能,如对数据操作的有效性和发生异常操作时对数据的保护功能(正确数据不丢失,数据回滚以保证数据的一致性)。其关键控制点有:对数据的存取控制及监视是否有效,是否记录数据利用状况,并定期分析,是否考虑数据的保护功能,是否有防错、保密功能,防错、保密功能是否有效等。
输出审计不同于测试阶段的输出审计,此时的输出是在实际数据的基础上进行的,对其进行审计可以对系统输出进行再控制,结合用户需求进行评价。关键控制点有:输出信息的获取及处理时是否有防止不正当行为和机密保护措施,输出信息是否准确、及时,输出信息的形式是否被客户所接受,是否记录输出出错情况并定期分析等。运行管理审计是对人机系统中人的行为的审计。
关键控制点有:操作顺序是否标准化,作业进度是否有优先级,操作是否按标准进行,人员交替是否规范,能否对预计于实际运行的差异进行分析,遇问题时能否相互沟通,是否有经常性培训与教育等。维护过程的审计包括对维护计划、维护实施、改良系统的试运行和旧系统的废除等维护活动的审计。
维护过程的关键控制点有:维护组织的规模是否适应需要,人员分工是否明确,是否有一套管理机制和协调机制,维护过程发现的可改进点,维护是否得到维护负责人同意,是否对发现问题作了修正,维护记录是否有文档记载,是否定期分析,旧系统的废除是否在授权下进行等。
三、审计完成阶段#
完成阶段是实质性的整个信息系统审计工作的结束,主要工作有:整理、评价执行审计业务过程中收集到的证据。在信息系统审计的现代化管理时期,收集到的数据己存储在管理系统中,审计人员只需对其进行分析和调用即可。复核审计底稿,完成二级复核。传统审计的三级复核制度对信息系统审计同样适用,它是保证审计质量、降低审计风险的重要措施。
一级复核是由信息系统审计项目组长在审计过程进行中对工作底稿的复核,这层复核主要是评价已完成的审计工作、所获得的工作底稿编制人员形成的结论;
二级复核是在外勤工作结束时,由审计部门领导对工作底稿进行的重点复核。在审计工作办公自动化的今天,二级复核制度同样可以通过网上报送及调用得以实现。评价审计结果,形成审计意见,完成三级复核,编制审计报告。
评价审计结果主要是为了确定将要发表的审计意见的类型及在整个审计工作中是否遵循了独立审计准则。信息系统审计人员需要对重要性和审计风险进行最终的评价。这是审计人员决定发表何种类型审计意见的必要过程,所确定的可接受审计风险一定要有足够充分适当的审计证据支持。签发审计报告之前,应当随工作底稿进行最终(三级)复核,三级复核由审计部门的主任进行,主要复核所采用审计程序的恰当性、审计工作底稿的充分性、审计过程中是否存在重大遗漏、审计工作是否符合事务所的质量要求等。
三级复核制度的坚持是控制审计风险的重要手段。审计报告是审计工作的最终成果,审计报告首先应有审计人员对被审系统的安全性、可靠性、稳定性、有效性的意见,同时提出改进建议。
四 、IT审计要求#
序号 | 范围 | 所需資料、文件 | 要求 | |
---|---|---|---|---|
1 | 公司层面控制 | · IT 部门架构图、IT 人员职责说明 | 1、 完整清晰的部门架构以及职员职责说明; | |
· IT 预算、策略和年度规划 (2005-2007 年) | 2、 有完善的费用预算机制,有经过授权并正式签发的费用预算文件;有与公司战略相匹配的IT策略及每年的年度规划; | |||
· IT 内部、IT 与业务部门、IT 与管理层之会议记录 | 3、 内部、与业务部门、与管理层之间的会议记录; | |||
· 与第三方供货商之服务协议 (若 IT 服务外判) | 4、 签订相关服务合同; | |||
· IT 风险评估制度和报告 | 5、 完善的风险评估机制,或引进专业风险评估机构; | |||
· 财务系统与其它系统间之数据流程图 | 6、 提供数据流程图; | |||
· IT 内部审计报告和审计发现之跟进 | 7、 应建立内审机制并定期内审,以辅助外审,建议引进专业机构定期内审。 | |||
2 | 信息安全 | 信息安全制度、用户信息安全意识 | · 信息技术安全规章制度 | 1、 制定完善的安全规章制度,并采取广泛的宣传措施将该制度灌输至每位公司职员。 |
· 令员工充份了解信息技术安全规章制度的措施 | 2、 规章制度写入员工手册并印发,新员工入职便能了解公司要求,并做定期培训,做好培训记录。 | |||
· 信息安全培训记录 | ||||
物理安全 | · 机房物理安全规章 | 1、物理要求:门禁系统、烟雾报警器(置于地板夹层或顶棚夹层)、监控、UPS、空调(接UPS)、干粉灭火器、防火防水装修材料; | ||
· 保安设施 (如门禁系统、访客记录) | 2、机房管理:专人管理钥匙、有访客记录、机柜门应上锁; | |||
3、服务器管理:密码变更设置(文档/流程/频率)、密码策略(windows/sql用户密码强制策略、windows帐号锁定策略、密码长度8位以上、历史密码6次)、windows界面自动锁定、应急管理/流程(备用钥匙、密码文件密封置于机房上锁的柜子中或密封的信封里面); | ||||
4、机房显眼处应有机房管理制度; | ||||
用户权限设定 | · 用户系统权限的列表 | 1、 用户权限组有详细的权限定义; | ||
· 用户设置不同系统权限之制度和审批等步骤 | 2、 完整的用户帐号增加、修改、删除审批流程; | |||
· 不同权限是否显示在用户申请表上 | 3、 用户帐号审批流程中应体现具体的权限选择; | |||
(需抽样申请表格 – 参见附注) | ||||
用户设定制度 | · 增加、更改、删除系统用户的步骤 | 1、完整的用户帐号增加、修改、删除审批流程; | ||
· 用户部门及 IT 部门审批程序, 申请表格之处理和保存 (需抽样申请表格, 可和上面的样本相同) | 2、有与人力资源中心提供的入职、离职名单相匹配的用户帐号增加、删除记录; | |||
系统密码设定 | · 系统密码设定 (应用系统层、操作系统层、网络层、数据库) | 1、密码长度应大于8位、应由字母和数字组成或者再区分大小写、客户端密码变更的频率应有控制(如30天强制要求变更密码); | ||
· 密码长度 | 2、错误密码登陆次数应不超过3次,且系统应用提示信息; | |||
· 密码最大更改日数 | 3、密码修改时应不允许与原密码相同的密码进行修改操作,应有历史密码控制策略; | |||
· 密码复杂性 | 4、对各种不同密码的变更频率及设置要求等应有完整的密码管理制度; | |||
· 可重用旧密码次数 | ||||
· 锁定用户前之容许错误登录次数 | ||||
用户权限审阅 | · 用户系统权限之定时审阅和复核, 及有关记录 (需抽样各阶段之文件及记录– 参见附注) | 1、对系统用户帐号的申请及权限分配等,应有定期进行复核的操作,并有相关文档记录,且文档应由相关领当定期审阅; | ||
超级用户 | · 应用系统、操作系统、数据库超级用户的申请、管理、使用审核的步骤和记录 | 1、对系统超级用户的使用应有审批授权制度,并有相匹配的流程; | ||
· 拥有超级用户的人员名单 | 2、对拥有超级用户权限的人员应严格控制; | |||
3 | 系统变更 | 系统变更管理 | · 系统变更管理规章制度 | 1、要求有完整的系统变更流程,流程中包括紧急变更的处理流程; |
· 系统变更审批、开发、测试 (用户及 IT) 之步骤及记录 (需抽样各阶段之文件及记录– 参见附注) | 2、变更过程中应有各种表单支持,如用户申请、上级审批、开发需求、IT测试、用户测试、实施记录、用户签收等相关表单; | |||
3、测试环境与正式业务系统环境应有严格区分,并有证据证明(可截图说明); | ||||
系统变更上线 | · 系统变更上线审批之步骤及记录 (需抽样文件及记录– 参见附注) | 4、紧急变更中应体现允许时候补走流程的内容; | ||
· 开发人员和上线人员之分工 (开发人员没有生产环境之权限) 之证明 | 5、系统中应有系统变更的日志记录,以方便查询历史变更; | |||
· 开发环境和测试环境之逻辑或物理分开之证明 | ||||
参数变更 | · 应用系统、操作系统、数据库系统参数变更管理规章制度 | |||
· 系统变更审批、测试 (用户及 IT) 之步骤及记录 (需抽样各阶段之文件及记录– 参见附注) | ||||
紧急变更 | · 无法循正常变更流程的紧急变更管理规章制度、审批、测试 (用户及 IT) 之步骤及记录 (需抽样各阶段之文件及记录– 参见附注) | |||
4 | 系统开发 | 系统开发方法论 | · 系统开发方法论 | |
(如适用) | 系统开发流程 | · 系统开发流程 (审批、开发、测试、上线) | ||
数据转换 | · 数据转换制度 (审批、测试、方案制定) | |||
5 | 信息技术运作 | 批处理工作 | · 日常系统批处理工作监察 (需抽样批处理核对清单– 参见附注) | 对于批量处理的事务应有完整的流程相匹配,如需要对数据源的确认、批处理完成后数据的校对。 |
备份制度 | · 系统备份制度、核对 (需抽样备份核对清单– 参见附注) | 1、完整在备份制度,包括数据备份及系统备份; | ||
2、每天的自动备份文件应保留6天以上而不能每天自动覆盖;且要有每天的备份任务执行情况的检查记录; | ||||
3、应有多重的备份机制,如本地磁盘备份、磁带备份、光碟备份、异地备份; | ||||
4、应有完善的备用环境,如异地双机热备; | ||||
5、对备份介质应定期进行恢复测试,有相关业务部门进行确定数据的准确性,并保留相关记录,该记录要求有用户、信息部门、管理层签字确认; | ||||
· 备份定期恢复测试制度和记录 (需抽样备份恢复测试记录– 参见附注) | 6、异地备份的物理环境应同于实际业务环境,以确保实际环境发生意外时备用环境能立即切换启用; | |||
· 异地备份制度 | 7、对于异地备份根据区域的不同可有不同的定义,不一定要求在5公里以上的间隔距离; | |||
· 异地备份之物理安全 (需抽样异地备份转移记录) | ||||
用户问题管理 | · 用户就系统有关问题之管理制度、问题处理、问题严重性分级、上报机制、问题汇总和审核制度 (需抽样问题处理记录– 参见附注) | 1、对问题管理应有完善的机制,包括问题收集、汇总,按严重性、紧急性分级,以及上报机制。 | ||
2、问题的处理应有跟踪反馈机制,确保问题被及时有效解决。 | ||||
6 | 最终用户应用程序管理 | · 对与财务报告有关之重要最终用户应用程序之管理制度 (如用户编制含 Macro 等程序之 Excel, Access 等) (如适用) | 1、相关软件的使用权(即正版软件)的购买应在预算中体现,并有购买的凭证; | |
2、对禁止使用盗版软件应有严格规定并依此执行; |