2430信息系统评估非ITA.docx
《2430信息系统评估非ITA.docx》由会员分享，可在线阅读，更多相关《2430信息系统评估非ITA.docx（17页珍藏版）》请在冰点文库上搜索。
2430信息系统评估非ITA
信息系统一般控制评估★
被审计单位：
索引号：
2430
页次：
编制人：
日期：
财务报表截止日/期间：
复核人：
日期：
根据瑞华审计方法指引《J40关于财务报表审计项目组与ITA团队整合的考虑》相关规定，IT分类属于第一类的客户需要根据“2610-1IT环境调查表”的结果，与ITA部门共同考虑公司信息系统环境的复杂程度，并据此共同协商确定是否在审计工作中引入ITA专家。
如经过完成“2610确定ITA专家的工作范围”的评估，认为不必引入ITA专家实施审计工作的，则项目组应完成本表格，对被审计单位的信息系统一般控制（ITGCs）进行评估。
IT分类属于第二类和第三类的客户，如果项目负责合伙人确定不引入ITA专家工作的，则项目组可以不填列“2610-1IT环境调查表”及“2610确定ITA专家的工作范围”，直接利用本表对被审计单位的ITGCs进行评估。
1、了解被审计单位的信息系统/信息技术环境-取得背景信息
重要的信息技术联络人：
姓名
职位
职责
被审计单位的信息处理系统和相关的支持活动的管理模式:
管理模式
是/否
描述
集中式管理
分散式管理
使用程度-主要财务系统：
应用项目
系统的提供者：
供应商/内部设计/终端用户
系统平台：
运行系统及数据库
任何短期内的修改?
财务分类账
采购订单处理流程
销售订单处理流程
存货
工资
固定资产
其它（请列明）
【注:
供应商可为Oracle，Sage，SAP等等。
内部设计指客户雇用程序设计师并且“拥有”系统的原始代码。
终端用户所开发的系统为非信息技术人士所设计（例如：
财务部门开发自己的发票数据库）。
系统平台：
被普遍使用的操作系统包括Unix、Windows、VMS等等。
被普遍使用的数据库包括Oracle、SQL。
“短期”的定义为在该会计年度期间之内。
】
客户信息系统的一般控制情况
（1）了解信息系统的一般控制
政策/程序
是否为现行的、且得到管理阶层批准的以及适当传播的？
需要副本？
信息系统/信息技术风险记录
信息系统/信息技术策略
信息系统/信息技术安全政策
合理的电子邮件/网络的使用政策
信息技术采购
系统发展/实施
客户端计算机使用需求
运行程序
设备管理程序
企业持续经营计划
信息技术灾难复原计划
【注：
项目组至少应取得信息系统/信息技术策略及信息系统/信息技术安全政策的复印件，以了解客户明年的计划。
如欠缺以上两项政策的复印件，则应针对此提供有关建议。
】
（2）评估信息系统一般控制的设计是否有效
控制说明
是否存在
相关控制说明
执行穿行测试情况（索引号）
1、客户能否确保以政策和程序来保证信息系统在管理和信息系统监控方面的有效性?
（1）是否拥有经相应管理层批准的正式的信息系统安全政策并将此政策与员工进行沟通。
（2）信息系统安全政策是否定期审核。
2、客户是否能够确保对程序、数据以及信息系统资产或服务的访问是被授权的?
（1）员工调入新的部门后会收到正式批准文件，从而可以对信息系统进行新的访问（或对访问的修改）。
（2）信息系统能够及时地识别并限制被解聘的员工对信息系统的访问。
（3）员工对应用程序资源码和产品数据的访问是受到限制的。
（4）拥有恰当的密码政策。
（5）管理员账户被限制在得到授权人员中使用，并且他们的访问要受到监控。
（6）信息系统经理定期对访问用户进行审核。
（7）建立适当的物理访问以限制非授权人员的访问。
3、客户是否拥有可行的政策以防止数据的损毁、不当的变更、未授权的交易或不准确的交易记录?
-
（1）针对应用程序，接口和数据传送安排（即，初始、批准和修改）的改变都建有正式程序。
（2）在接口和定期的数据传输（包括备份）方面的变更要在实施前进行测试，以确保它们符合具体要求同时满足商业及用户的需要。
（3）程序向生产环境的转换与程序的研发/编制分开的。
（4）建有紧急程序修改流程（即，批准、测试、记录、监督）。
（5）已经建立了对生产数据及数据结构进行访问/修改的正式流程（即，审批、测试、记录和监控）。
4、客户是否能够确保拥有政策以避免对系统/程序的依赖，特别是当系统/程序在处理数据是出现误差、或对有误差的数据进行处理时?
-
（1）为报告、管理以及问题解决/事件建有正式程序。
、
（2）对定期数据传输进行监控以便及时发现并解决问题。
、
（3）建有备份政策以及程序（即：
频繁程度，审核，贮藏，留存，测试及记录）。
（4）建有灾难恢复计划。
【程序说明：
1-
（1）确信存在着信息安全政策并观察通过互联网或邮件进行的沟通。
1-
（2）观察信息安全政策是否在过去的2年间得到了更新。
.
2-
（1）观察通过申请表或邮件审批的对新的，或修改后的访问情况。
2-
（2）询问那些已经离开组织的用户的远程访问流程。
这些应当在该用户离开组织的一个月之内完成。
2-（3）询问谁可以访问资源码和生产数据，并确定他们的工作是否需要访问这些信息。
会计部门的人员不应当具备访问资源码或生产数据的能力。
2-（4）观察在用户登录时是否使用了复杂的密码。
复杂密码的最低要求:
最少长度:
6个字符
密码使用时间:
以前密码重复使用不可以超过3个
密码有效期:
密码必须在90内更换
访问在5次密码错误之后要被锁定
密码必须是字母加数字
2-（5）观察记录是否有效，使得由系统管理员账户实施的活动也能够被记录下来，而且这些记录能够定期地被审核。
要确保只有授权人员才能够接触到管理员密码（而且他们的工作也需要有秘密）.
2-（6）观察部门领导每年至少2次对访问权限进行审核（特别是会计部门）
2-（7）观察数据中心（计算机/服务器房）是否被恰当地进行了限制（即，通过给门上锁，密码保护，等）。
3-
（1）询问对商业应用系统的变化、数据库、网络及操作系统的支持和观察，批准和修改等方面的流程。
3-
（2）若在不同的商业应用系统间存在着自动的数据传输，要询问变更，测试，及时间安排是如何得到批准的。
（包括备份数据）
3-（3）观察从测试到生产程序的改变是否只限制在除开发人员外的有限的用户范围内。
若不是，询问所进行的活动中，如从测试到生产程序升级的编码中是否有记录并得到审核。
3-（4）询问该组织是否具备紧急变更流程.。
3-（5）询问该组织是否具备修改数据架构（数据库）的流程。
4-
（1）询问处理商业应用中出现的问题的流程，以及对信息系统设施的支持情况。
4-
（2）询问用来监控定时数据传送的流程。
4-（3）询问关于备份政策及程序的有关情况。
确保备份政策能够就关键会计数据的备份进行恰当地概述。
4-（4）观察是否有灾难恢复程序。
】
2、评估信息系统环境的复杂性
问题
非复杂
（1分）
复杂
（4分）
评分
（1-4分）
信息技术部门：
是否有许多信息技术人员执行技术性任务，以致财务应用程序或其数据的完整性可能受到影响？
【注：
右栏的“支持”仅包含基本的行政责任，如：
增加及移除使用者，但不包括技术上诸如更改数据库的数据的类似任务。
】
【信息技术部门拥有少于四位员工支持第三者的应用程序及计算机】
【信息技术部门的规模较大（或具有签定设备管理合约设备）并且具备支持内部设计应用程序的发展能力】
系统整合：
各财务应用程序是否得到整合或集中？
【注：
已整合的系统通常为现成的软件包，如：
CFACS或Sunaccounts。
ERP系统（例如：
SAP及Oracle）容许大量的系统更改，并被视为复杂。
】
【具有涵括整个关键财务流程的财会程序（例如：
采购、销售、存货及工资）】
【透过五个或以上的独立交易系统取得财务数据（系统可能分布于不同地点或包括客户端所开发的数据库及表格程序）】
交易处理：
财务应用程序开始及核准交易至什么程度？
【注：
租金计算可作为自动开始及核准的例子】
【所有交易要求人工核准】
【交易的开始并不需要人工授权】
系统存取：
财务应用程序的存取（或潜在存取）途径增加XX的存取风险。
有多少数目的计算机/终端机有可能进入拥有财务应用程序的计算机系统？
【注：
”潜在”意指非财务用户可经由直接/间接的方式存取财会主机的数据。
】
【财务系统拥有其独立网络，或整个系统不允许远程访问及连接少于50部计算机】
【系统在主要业务网络的上并连接广大地区的远程用户，例如：
通过互联网。
【
特别事件：
出现特别的信息系统/信息技术的事件，如：
:
∙系统的修改或重要信息技术人员的更换;
∙系统操作失败，而并没有立刻恢复
∙发现舞弊或黑客入侵
【该年并没有发生严重事件】
【发生对系统完整性有重要影响的事件】
总分
【注：
在此部份，财务应用程序包括所有用作取得财务信息的企业应用程序（并不仅限于分类账）】
3、评估信息系统对业务的重要性
对业务的重要性
非常重要
重要
不重要
请描述如果计算机系统不能运行而给业务造成的中断程度。
如果没有计算机公司能合理地运营多久？
请说明如果系统处理发生重大错误会有哪些短期和长期的影响？
错误的发现需要多久？
以及该错误将如何影响业务？
为了及时和准确地处理业务，业务对计算机的依赖程度如何？
每天所做的决策是否基于计算机系统的数据？
4、评估信息系统/信息技术风险对事务所审计风险的影响
（1）风险–信息系统一般控制设计无效或没有有效运行的风险
增加风险的因素
减低风险的控制
证明一般控制有效运行已执行的审计程序
控制设计及运行是否与风险密切配合？
【注：
在第一栏填写增加此风险的可能性或影响此风险的事项。
可能包含的例子如下：
-组织的规模
-监管措施，如侵略性风险管理程序
在第二栏填上客户为管理或降低风险所做的事项。
可能包含的例子如下：
-连接资深管理阶层/行政人员/董事会的信息技术部门报告专线
-管理此业务的专业机构（例：
指导委员会）
-信息技术部门内的分工（例：
信息技术人士为“正常业务程序”的一部份）
-根据业务需求而配备信息技术员工
在第三栏描述取得此信息的途径。
例子如下：
-与信息技术管理阶层的讨论
在第四栏做出判断。
负面因素与正面因素是否平衡？
风险是否迟早会发生？
公司是否控制过度？
风险过度的控制对公司造成的伤害可能并不亚于不足的控制。
】
（2）风险-系统的完整性可因更改而受破坏
增加风险的因素
减低风险
的控制
证明控制有效运行已执行的审计工作
控制设计及运行是否与风险密切配合？
【注：
在第一栏填上增加此风险的可能性或影响此风险的事项。
例子如下：
-系统更改的次数
-信息技术开发小组的规模
-内部信息技术发达程度与对外界厂商的依赖程度的比较
在第二栏填上客户为管理或减低风险所做的事项。
例子如下：
-管理层/指导委员会批准及优先处理的系统重要更改
-使用明确的计划管理方法（例：
PRINCE2）做出更改
-已建立正式的程序/数据更改的控制程序，以避免出现未经批准的临时更改
-与外界厂商签订转移风险或指明对数据/系统有限度存取的合约
在第三栏描述取得此资料的途径。
例子如下：
-与信息技术管理层的讨论
在第四栏做出判断。
负面因素与正面因素是否平衡？
风险是否迟早会发生？
公司是否控制过度？
风险过度的控制对公司的伤害可能并不亚于不足的控制。
】
（3）风险-不适当的服务提供方式因而增加失败的风险
增加风险的因素
减低风险的控制
证明控制有效运行已执行的审计工作
控制设计及运行是否与风险密切配合？
【注：
在第一栏填上增加此风险的可能性或影响此风险的事项。
例子如下：
-信息系统/系统支持的复杂程度
-系统对企业营运的重要性
-客户迅速发现错误的能力
在第二栏填上客户为管理或减低风险所做的事项。
例子如下：
-明确订立及遵循正式准则、政策及程序
-对活动做出监督
-并非仅依赖一名重要工作人员的知识
在第三栏描述取得此资料的途径。
例子如下：
-与信息系统管理层的讨论
在第四栏做出判断。
负面因素与正面因素是否平衡？
风险是否迟早会发生？
公司是否控制过度？
风险过度的控制对公司的伤害可能并不亚于不足的控制。
】
（4）风险-存取控制不能防止对财务数据不适当的存取
增加风险
的因素
减低风险的控制
证明控制有效运行已执行的审计工作
控制设计及运行是否与风险密切配合？
【注:
在第一栏填上增加此风险的可能性或影响此风险的事项。
例子如下：
-被授权的（财务）使用者的规模及地点。
-网络的规模（使用网络的总人数）
-产业（例：
金融机构为较高风险的产业）
在第二栏填上客户为管理及减低风险所做的事项。
例子如下：
-财务服务器硬件被妥善保管。
-系统拥有良好质量的密码控制，以减低XX的存取风险
-系统记录各使用者的行动
-网络架构的设计明确的限制非财会人员存取财务系统
在第三栏描述取得此资料的途径。
例子如下：
-与信息技术管理层的讨论
在第四栏做出判断。
负面因素与正面因素是否平衡？
风险是否迟早会发生？
公司是否控制过度？
风险过度的控制对公司的伤害可能并不亚于不足的控制。
】
5、结论
复杂程度：
将第二部分的分数加起来。
总分超过10分，被视为“复杂”。
信息系统环境是否“复杂”（是或否）？
___________
使用程度：
根据第一部分被审计单位对信息系统的的使用范围，对被审计单位信息系统的使用程度进行评价
被审计单位信息系统的使用属于“广泛”、“一般”、“局限”？
___________
对业务的重要性：
根据第三部分信息系统对业务的影响程度，对被审计单位信息系统对被审计单位业务的影响程度进行评价
信息系统对被审计单位业务的影响是“非常重要”、“重要”、“不重要”？
___________
被审计单位使用计算机的整体分类评价：
基于上述的了解及评价，对被审计单位使用计算机的整体分类评价为:
描述
高度计算机化
中度计算机化
轻度计算机化
审计风险：
将第四部分的结论列在下面的表格：
风险范围
控制是否令人满意？
（是/否）
如答案为“否”，事务所应采取什么行动？
*
不良的信息系统/信息技术行政管理会减低信息技术部门执行其职责的能力
系统的完整性可因更改而受破坏
非正式的提供服务方式增加失败的风险
存取控制不能防止对财务数据不适当的存取
【注：
“行动”可包括提出改善或建议信息系统审计团队成员与客户讨论有关问题。
】
根据你的判断，客户的信息系统控制是否不足，以致存在对事务所发表审计意见可能带来负面影响的重大风险？
（是/否）？
___________
编制说明：
在填写本表格时﹐我们应当记录所获取的信息和审计证据的来源。
本表格是对被审计单位计算机的使用程度、复杂程度及对业务的重要性进行了解及评估,进而对被审计单位使用计算机的整体情况进行分类。
被审计单位使用计算机情况的整体分类为:
高度计算机化—广泛使用计算机，计算机环境复杂，且计算机系统对业务非常重要。
如果被审计单位使用企业资源策划（ERP）系统，如SAP、PeopleSoft或OracleFinancials，或者被审计单位拥有数据库技术（SQL、Oracle等），那么这样的被审计单位通常都属于高度计算机化客户。
高度计算机化客户依赖于计算机进行日常运营。
他们通常拥有一个或多于一个的网络和/或计算机环境。
他们的交易量较大且依赖计算机进行大多数决策。
中度计算机化—使用计算机程度低于“高度”，但高于“轻度”。
中度计算机化被审计单位往往有—到两种复杂的计算机系统，这—到两种系统被广泛地使用而且对业务是重要的，但就整体而言，被审计单位使用计算机的程度尚不足以归类为“高度”。
如果被审计单位使用局域网（LAN）或互联网接入，则通常表明该客户是中度计算机化客户。
如果应用程序是集成化的，或使用自动接口程序，那么这个计算机环境通常至少是“中度”的。
使用简单的总分类账模块但依赖计算机进行库存管理或销售和订单管理的用户通常也属于中度计算机化。
如果被审计单位在多个地点使用各自的系统，也属于中度计算机化。
轻度计算机化—使用计算机的范围局限于处理一些对业务不是十分重要且比较简单的工作。
如果被审计单位只有一个相对简单的计算机应用程序（如，工资和总分类账）并且不应用于日常运营，那么就将被审计单位归为此类。
只有3到4人使用计算机系统或大多数工作由手工完成的客户也划归为轻度计算机化。
对于被分类为高度或中度计算机化，但根据本所审计技术指引J40，其IT分类不属于第一类的被审计单位,建议项目组与信息系统审计团队（ITA）讨论该被审计单位IT环境的复杂性，据此共同确定是否需要引入ITA的审计，以及利用ITA专家工作的性质、时间和范围；对于被分类为轻度计算机化的被审计单位，亦需记录对被审计单位信息系统的了解及评价。
升级会员 