业规606号已取消信息系统审计试行.docx
《业规606号已取消信息系统审计试行.docx》由会员分享，可在线阅读，更多相关《业规606号已取消信息系统审计试行.docx（82页珍藏版）》请在冰豆网上搜索。
业规606号已取消信息系统审计试行
信息系统审计业务规范（业规606号）
信息系统审计概述
信息技术对企业的影响
信息技术，从广义上讲，凡是能扩展人类信息功能的技术，都是信息技术。
具体而言，信息技术是指利用电子计算机和现代通信手段实现获取信息、传递信息、存储信息、处理信息、显示信息、分配信息等的相关技术。
随着信息技术的发展，企业使用计算机处理信息的范围和用途也是不断发展。
从最初的利用计算机处理部分会计资料，发展为为企业提供业务支持，再继而使信息技术与企业业务高度融合，最后成为企业发展与运营所依赖的信息技术平台。
信息技术审计的演变
在计算机产生以前，企业内部的信息处理最初是以手工处理的方式进行的。
一个企业的会计部门，通过不同岗位之间的分工协作，将日常经营活动中产生的财务资料进行加工处理，形成企业内部和外部需要的各种纸质会计信息。
这种情况下的审计方式毫无疑问是手工的形式。
随着计算机的普及尤其是微型计算机的大众化，一些企业开始用计算机来处理会计资料。
例如，企业内部执自行开发的工资管理系统、存货管理系统等，逐步用计算机代替了部分人工劳动。
但是，由于计算机处理的范围还比较小，注册会计师可以忽略计算机的存在，直接对打印出来的纸质文档进行审计。
由于会计信息技术化的大规模普及，大部分企业的会计处理已经实现信息化。
注册会计师开始意识到信息技术审计的重要性。
但这时人们对信息技术审计的认识还停留在对财务数据的采集和分析阶段，注册会计师仍然可以绕过信息系统，对财务数据和报表进行核实，以获取审计证据。
伴随着会计信息化的成熟，以ERP为代表的企业信息系统的高度集成逐渐开始兴起。
这时的企业信息系统已不仅是一个独立的系统，而是集财务、人事、供销、生产等位一体的综合性系统，财务信息只是这个系统所处理信息的一部分，因此，注册会计师必须在规划和执行审计工作时对企业信息技术进行全面考虑。
而实际上真正把信息技术审计纳入审计工作内容的分水岭是是2001~2002年爆发的安然、世通丑闻，美国国会草拟并通过了《萨班斯－奥克斯利法案》（SarbanesOxleyAct2002），其中404条款明确了信息技术审计的重要性。
从此，信息技术审计在全球范围内开始快速发展并逐渐被公众认可。
下图是信息技术审计演变的过程：
信息系统审计的作用
信息系统审计是一个过程，在此过程中搜集和评估证据以确定信息系统和相关资源是否充分保护、维持数据和系统完整性、提供相关和可靠信息、有效实现组织机构目标、有效使用资源、包含有效内部控制以提供运营和控制目标得到满
足与合理保障。
通过收集并评价审计证据，以判断与被审计单位的信息系统相关的资源与资产的保全、资料与系统的完整性维护等；判断信息系统是否可以提供值得信赖的资料，并有效实现组织的目标；信息系统的内部控制是否有效地实现控制和经营目标，并能及时地预防、发现和纠正不良事件的发生。
信息系统审计与财务报告的关系
信息技术一般性控制通常会对已实现的部分或者全部财务报告认定做出间接贡献。
有些情况下，信息技术一般性控制可能对实现信息处理目标和财务报告认定做出直接贡献。
这是因为有效的信息技术一般性控制能能够确保依赖于计算机处理流程的应用控制和自动的会计处理过程控制持续有效。
如果想依赖自动的应用控制、自动的会计处理过程、或者生成信息的那些应用，必须对信息技术一般性控制进行评估。
由于在程序变更、程序开发、信息系统维护操作以及程序和数据安全之上的控制会影响应用方面操作的有效性，所以在这些领域的控制测试也是必要的。
信息系统审计与财务报告的关系
上图中的数字注解：
1、管理层通过发布这些报告暗示着财务报告的这些认定
2、财务报告的科目余额来源于一个或多个事务交易
3、对于不同的事务交易类型存在着一些公用的处理过程这些事务交易就经常组成子流程
4、子流程组成业务流程，能够使管理层有效的管理
5、管理层确定关于事务处理流程的目标
6、实现信息处理目标中存在的风险
7、管理层通过实施应用控制降低或者减轻信息处理目标中的风险
8、管理层通过实施业务绩效审阅来识别潜在的财务异常情况
9、管理层评价在应用控制中是否存在财务异常情况
10、一定的手工应用控制和业务绩效审阅使用的报告是通过计算机应用生成的
11、有效的信息技术一般性控制有力的支持了管理层信赖自动的应用控制、自动的会计处理过程、使用应用产生报表的那些手工控制
12、有效的应用控制会对财务报表认定做出直接贡献
增加审计信心
信息技术一般控制对审计信心的贡献，具体参见下表：
审计师对信息系统的依赖程度
对系统环境的了解与评估
验证手工控制
验证系统应用控制
了解、验证系统一般性控制
不依赖
是
否
否
否
仅依赖手工控制，此类手工控制不依赖系统所生成的信息或报告
是
是
否
否
仅依赖手工控制，此类手工控制依赖系统所生成的信息或报告，审计需要通过实质性测试来验证控制有效性
是
是
否
否
同时依赖手工及自动控制
是
是
是
是
信息系统审计范围确定
信息系统审计是对财务审计的有力支持。
而信息系统审计的范围也是围绕财务审计展开的。
信息系统审计范围的确定主要是对信息系统的确定。
一家企业可能拥有多个信息系统，是否进行信息系统审计，或者对哪些信息系统纳入审计范围，是需要进行评估的。
具体的评估方法如下：
重要科目、重要业务流和重要系统之间有一个逻辑对应关系（Mapping），通过这种方法就可以确定信息系统审计的系统范围。
系统范围对于信息系统审计来说，非常的重要，它决定着审计的范围、工作量、审计成本等。
确定重要会计科目
“重要”一词不仅局限于定量的重要性，某些科目可能从定性的角度或因被投资者视为重要的业绩衡量指标而被看作为重要的会计科目。
需要考虑的因素包括：
▪合并财务报表中单独披露的科目
▪定性和定量因素
▪合并财务报表层面的重要性水平
为了确定重要会计科目，管理层应在完全不考虑对于财务报告的内部控制有效性的情况下，对错报的可能性进行评估。
对于重要性的定性分析往往是一个专业的主观判断。
同时，为了确定哪些会计科目是重要的会计科目，管理层必须了解重要性水平的概念。
在财务报表编制中使用的重要性水平的定义适用于财务报告内部控制的有效性的计划和报告。
重要性水平不只是一个量化的概念。
对重要性水平的判断具有主观性，还可能在项目实施过程中发生变化。
重要性水平的概念适用于合并财务报表和单个科目/明细科目。
我们认为在确定其内控测试范围时，应考虑下列几个标准：
总体重要性水平：
总体重要性水平涉及合并财务报表的重大错报风险。
管理层在评估重要性时应考虑美国证券交易委员会第99号会计公告-重要性水平中提供的指引内容。
针对某些重要的计量标准，如税前利润，采用重要性水平（如：
5%）的方法有利于初步判定科目是否属于重要会计科目。
此外，总体重要性水平是用来评估单个重要会计科目的总体错报（以及内控审计中的总体缺陷）对于合并财务报表是否具有重大影响。
计划重要性水平：
我们认为计划重要性水平一般根据损益表科目进行计量，比如税前利润（损失），并且应用来确定单个会计科目（或科目的明细科目）的重要性。
为了充分考虑各会计科目错报的总和以及检查风险（控制未发现重大错报事项的风险），计划重要性水平应低于总体重要性水平。
我们认为，计划重要性水平根据风险级别的不同（比如，高风险公司的计划重要性水平较低，低风险公司的计划重要性则较高）一般应保持在总体重要性水平的50%到75%左右。
举个例子说明，如果总体重要性水平定为影响税前利润的（损失）1百万美元，那么对于高风险公司的计划重要性水平则可能为50万美元（即1百万美元的50%），低风险机构的计划重要性水平则可能为75万美元（即1百万美元的75%）。
确定重要业务流程/循环/子循环
确定重要业务流程/循环和子流程/子循环的同时，还要确定其与重要会计科目和披露事项的对应关系
“确定对应关系”是指将重要会计科目和生成这些重要会计科目的业务流程/循环或子流程/子循环联系起来。
这一步骤有助于确保所有重要的会计科目都能与业务流程/循环对应以及确保所有的重要业务流程/循环均被识别。
如果管理层无法识别所有这些流程，那么确定针对相关认定的控制活动将更加困难。
在每个业务程序和子流程中，管理层明确哪些控制活动是针对实现信息处理目标/CAVR的活动。
信息处理目标/CAVR指的是信息处理目标的完整性、准确性、有效性和接触限制。
在审计过程中涉及到的重要业务流程或者循环，应该是与重要会计科目存在着一定的对应关系，换句话说，这些业流程/循环出现异常会直接/间接的影响重要会计科目，从而影响财务报告。
风险评估
风险评估贯穿整个审计过程，同时根据了解的情况会作适当的调整。
风险评估结果将被用来评估对各领域的测试工作的性质、时间和范围。
风险评估的方法很多，但我们应该在风险评估的方法上要坚持一贯性原则。
对于各因素的风险评估，三种评级（高中低）的解释建议如下：
风险级别
解释
高
错报的可能性很高，或者科目余额对财务报表有重大影响。
中
财务报表中某领域内出现错报的可能性一般，或者该流程可能出现错误的严重程度一般。
低
该流程很简单，且该领域的错报对财务报表的影响很小。
确定重要经营场所覆盖率/经营场所
这也是信息系统审计范围的一部分。
如果该企业有多家分支机构，而财务审计小组已经确定了经营场所，信息系统审计小组只需对确定范围内的经营场所的信息系统进行审计即可。
举例说明：
经营场所
是否纳入审计范围
信息系统
是否纳入范围
A
Y
System1
System2
Y
N（不是重要业务流程对应的系统）
B
Y
System3
Y
C
N
System4
N
D
Y
System5
Y
通过上表，我们可以得出系统审计的系统范围：
经营场所
系统审计清单
A
System1
B
System3
D
System5
如何确定经营场所覆盖率/经营场所呢？
可以通过下面的决策流程图执行：
识别重要信息系统
通过以上重要业务流程、重要经营场所的确定，在财务审计小组的帮助下，系统审计小组可以梳理出信息系统清单，从而与重要业务流程建立对应关系（Mapping）。
到此步，我们基本确定了信息系统审计的系统范围。
有了系统清单，我们就可以会制定一系列的审计内容，具体参见下一章节的“信息系统审计内容”。
信息系统审计内容
信息系统审计的内容主要分为两大部分：
信息技术一般性控制（ITGC）和应用控制（ITAC），具体的描述见下：
信息技术一般控制-ITGC
信息技术一般性控制（InformationTechnologyGeneralControl）是为保证信息系统的安全，对整个信息系统及外部各种环境要素实施的、对所有的应用或者控制模块具有普遍影响的控制措施。
包括5个领域方面的内容：
信息系统控制环境
信息系统环境控制也称公司层面控制（以下简称公司层面控制），是贯穿整个公司运营的控制（包括公司和业务单元/管理单元层面）。
为了快速获取在财务报告之上的内部控制是否有效，单独进行公司层面控制测试是不够的。
尽管公司层面的控制与流程、交易，或应用层面的控制有着间接关系，但在一些情形下却有着直接的关系（比如某些健全的业务绩效审阅）。
无论哪种情形，公司层面的控制都会影响控制测试的性质、时间和范围。
在决定基础的流程、交易或者应用层面控制测试的性质和范围时，间接的公司层面控制的质量和有效性是需要考虑的因素。
如果直接的公司层面控制存在，并且有效，满足控制目标或者相关财务报告认定，我们应该排除基础的流程、交易或者、应用层面控制的测试。
公司层面控制测试的内容主要包括4个方面：
内容分类
主要内容
控制环境
●IT治理：
是否建立了和公司战略及总体控制环境一致的IT治理框架？
IT主管人员是否定期向董事会和审计委员会汇报？
IT管理者如何定义和界定风险、控制及舞弊？
IT战略的制定是否考虑了业务战略的因素？
●IT职能和资质：
IT部门的组织结构是否达到权责分离，职责明确？
IT管理者怎样确保本部门的员工都参加了必要的相关培训，并且确保他们的知识不断更新？
●人力资源：
是否对IT部门敏感职位的雇员进行了人员背景调查？
是否有职业道德、公司行为规范等方面的培训？
●IT资产管理：
是否对信息资产的所有者进行了清晰的定义？
是否编制了资产清单，是否对信息资产的使用制定了规章制度？
●信息分类：
信息是如何进行分类的？
是否建立适当的流程对分类信息进行标识？
风险评估
●IT目标与风险：
IT风险评估是否针对包括IT职能外包等内容进行了足够细化？
IT风险评估又是怎样与公司层面的风险评估相互联系和沟通的？
●应对IT风险变化：
是否存在机制来发现和回应由于IT职能和技术环境变化所带来的风险？
本年度都发生过哪些重大变更（如采用新系统、由手工控制变为自动控制、系统软件的重大变更、外包等），管理层又是如何应对由此带来的风险？
有何长期计划？
●风险缓释与剩余风险：
IT管理者如何确保通过预防性控制和发现性控制的适当组合来降低风险？
IT管理者如何判断是否能够接收剩余风险？
信息与沟通
●信息的获取与信息的质量：
IT部门的员工是否能够获取足够的信息来有效执行信息系统总体控制？
管理层是否对系统功能上的重大问题/缺陷、重大的操作故障、安全事故或数据损坏问题的了解程度和采取的补救措施？
●数据所有权：
是否在业务部门中确定了业务数据的所有者？
是否清晰地规定和传达了数据所有者的责任？
●IT控制的有效沟通：
如何对IT部门的员工有效地传达他们的控制责任？
IT管理者是否乐于从IT部门员工和业务部门最终用户那里获得反馈意见？
针对特定法规对内部控制的相关要求，IT管理者是否明白他们自身应承担的责任？
●最终用户计算/处理：
有哪些IT控制的重要责任是由非IT部门来承担的？
管理层如何保证这些部门的员工完全理解有关的IT风险并具备足够的IT控制知识？
监控
●持续监控：
IT管理者如何监控信息系统总体控制在日常工作中是否得到有效执行？
是否也会监控外包的IT职能？
质量保证部门是否能有效地发现违背IT政策规定的情况？
●时点监控：
内部审计计划是否适当涵盖了IT方面的风险？
是否定期进行IT部门及信息系统总体控制的合规性检查？
IT管理者如何保证第三方的控制能够持续有效？
●IT安全部门的监控：
如何评估数据中心、开发中心内部的安全部门的工作效果？
●缺陷的沟通：
IT内部控制缺陷在内部如何汇报？
董事会和审计委员会如何获知监控活动的结果？
信息系统开发
信息系统开发控制是从信息系统生命周期的角度，审视每个环节的控制措施和执行情况，包括项目可行性分析、需求分析、系统设计、用户接受测试、项目验收、三环境是否分离（开发环境、测试环境、生产环境）、用户权限划分是否职责分离等等。
内容主要包括8个方面：
内容分类
主要内容
对程序开发活动的总体管理
●是否有一套正式的系统开发方法？
使用了何种工具来管理和控制开发活动？
●是否制定了一个详细的项目计划，并应用于程序开发生命周期的所有方面？
●是否定义了项目每个阶段的责任部门和应交付的成果，由发起开发的用户和IT部门共同认可？
管理层是否审阅适当的项目进度报告并签字认可？
项目发起
●项目是否有明确的业务目标与清晰的范围和边界？
●在项目的发起阶段是否有全面的可行性分析？
●在高级管理层中是否有明确的项目发起人/所有者？
●项目小组是否有充足的相关业务与技术经验，能根据设计方案有效地完成项目？
分析和设计
●是否明确了高层管理者、用户和IT员工中明确利益相关的参与者？
●是否有明确的业务功能、性能要求、安全设计和内部控制等方面的需求？
并编制了基于用户要求的业务需求书、详细技术设计、程序设计说明书、流程和数据建模等。
●是否有业务部门管理者的签字认可？
程序编译
●是否遵循了标准的编程方法?
●要识别和考虑各个集成的应用系统之间的相互依赖性。
●对于外购的现成系统，如何选则软件包？
是否还需要定制？
测试和质量保证
●开发环境、测试环境和生产环境是否分开？
●具体的测试是否包括单元测试、系统测试、集成测试、用户接受测试？
●测试应保证交付的系统达到了“分析与设计阶段”制定的业务和内部控制要求。
●如何保证经过了测试但尚未上线的程序不被更改？
数据移植
●是否所有采用了新的数据模型的数据都经过转换？
是否所有数据字段都从旧系统恰当地映射到了新系统？
●如何确保关键字段的数据质量，包括准确性、完整性、连贯性、可用性和存在性？
●是否需要修改关键系统接口以接受新的数据模型？
系统上线
●项目发起者、用户部门管理者和IT部门管理者是否正式批准投产？
●是否通知了所有利益相关方？
●是否制定了回退策略和问题上报流程，并启动了投产后的活动？
文档与培训
下列活动虽然是该部分的内容但通常会在决定上线之前就进行：
●编写用户手册和技术手册；
●正式的业务培训和技术培训
信息系统变更
信息系统变更的目标是确保与程序、相关基础组件的变更经过了申请、审批、执行、测试，达到管理层控制的要求。
内容主要包括6个方面：
内容分类
主要内容
对维护工作的管理
●正式的统一标准和工具用以对业务系统和IT基础构架的变更进行管理
●正式的统一的变更状态报告机制贯穿于整个维护工作过程中
●正式的变更审核流程
●明确定义角色和职责，包含那些在整个维护阶段确保用户的参与的相关内容
申请、授权和跟踪变更处理
●变更的集中记录、追踪和管理机制
●有详细的应用系统变更说明书和测试计划，同时得到应用系统使用部门的审批同意
●紧急变更：
相关流程对变更的授权进行规定。
应保证有续流程来对变更的准确性进行测试
●微小变更：
通常被误认为微小变更没有必要走正规流程，但这种想法是错的。
很多生产中的问题都是由于没有经过测试的小变更进入生产环境而造成的。
在走“捷径”的时候，应当考虑它所带来的潜在风险
程序编译
●是否有源代码的版本控制机制及标准的编码规范？
●如何明确各个业务系统之间的依赖关系？
●如何确保用于变更的源代码与当前用于生产的版本一致？
●在开发环境中分离和控制如何对源代码的访问权限进行控制？
测试和质量保证
●存在正式的政策和相应控制来保证开发环境，测试环境和生产环境相分离
●建立最低的测试标准
●根据变更的范围，有正式的流程来确保用户参与对变更进行的测试
●管理层对质量保证进行独立的复核并对所有投产的变更给于授权
●存在相应的机制用以防止和发现在测试结束尚未投入生产环境前的非法变更
迁移到生产环境的授权
●存在正式的流程用以在生产环境中安排，沟通，协调和执行变更
●存在相应控制以防止对生产环境数据的非授权访问同时保留审计证据
●存在正式的政策来管理紧急变更
●所有变更都要有回退流程
文档及培训
所有的业务应用系统变更和IT基础架构变更均需有相应的正式文档和培训，考虑如下方面：
●有相应流程确保用户和技术文档得到相应更新，从而能够反映出所有变更。
●有相应流程确保所有相关的部门和人员都得到适当的培训
信息系统运行安全
信息系统运行安全是确保生产环境的处理满足财务、运营、业务发展的要求。
内容主要包括7个方面：
内容分类
主要内容
对计算机操作活动的总体管理
●是否制定了运行操作方面的正式流程和规范？
如何确保及时更新该流程规范？
●所有关键岗位的职责和责任是否已明确定义并及时更新？
操作人员是否理解他们各自的岗位职责？
●管理层如何保证计算机操作人员拥有恰当的技能和参考文档来完成他们的工作？
●现有岗位设置能否满足适当的职责分离？
批处理程序的编写和执行
●如何维护和更新批处理程序以保证他们定时运行？
●是否存在恰当的作业计划和作业编排流程？
●待处理的数据是否持续可用？
●是否存在一贯的流程和恰当的文档供检查和参考？
备份管理
●有无正式的备份管理政策？
●对数据和程序的备份流程、备份保存周期和备份介质存储的规定是否适当？
●如何保证系统和数据能从备份介质中成功恢复？
●管理层是否定期监控备份管理活动？
数据中心物理环境管理
●如何放置和保护计算机设备以防止意外损害（包括火、烟、水、灰尘、化学物质和电磁辐射等）？
●如何确保计算机设备的电源持续供应？
●如何降低系统遭受意外损害的风险（包括火、烟、灰尘、化学物质等）？
从操作故障中恢复
●如何确保及时发现和解决运行故障，并确保该解决过程得到相关人员事后认可？
●如何记录故障？
●解决运行故障的流程是什么？
●在灾难时，如何确保能够异地恢复重要系统？
●如何排定恢复关键数据和系统的优先顺序（如：
让管理层适当参与）？
技术支持
●如何应对、回答和记录与系统相关的疑难和问题？
●是否有正式成文的服务台操作流程和程序？
●如何确保服务台操作程序的及时更新？
服务水平协议
●服务水平协议是否充分保证了业务系统与财务系统能够得到适当的IT支持？
●如何监督服务水平协议的执行情况？
如何处理违背服务水平协议的情况？
对程序和数据的安全访问
该领域的目标是确保只有合法用户才能访问经过授权的资源。
内容主要包括8个方面：
内容分类
主要内容
信息安全组织机构和管理
●管理层对信息安全智能方面的规划和设计是否基于对信息完整性风险的评估？
●管理层在规划信息安全职能时，是否考虑到职责分工？
●从数据所有者的角度出发，是否每个业务单元的管理层均被适当的考虑在信息安全职能的设计中？
●在信息安全职能中，管理层是否推行了相关人事政策和程序，是否明确定义了岗位职责？
安全政策和程序
●为达到信息完整性的目标，管理层是否制定了一系列安全政策和程序？
●管理层针对安全政策和程序的定期更新、完善建立了哪些流程？
●管理层对信息技术部门和业务部门用户进行安全政策、流程和相关职责定期培训制定了哪些流程？
应用系统安全管理
●制定了哪些系统安全管理程序，以确保应用系统的访问权限均经过有效的审批？
●应用系统安全管理程序中，对于应用系统以及由业务部门负责管理的财务数据的访问权限，是否规定需经过业务部门管理层的审批？
●对于集中管理的应用系统，业务单元管理层是否定期审核用户的访问权限，以确保用户的访问权限和用户的岗位职责相符合？
数据安全管理
●管理层制定了哪些政策或流程来限制不通过应用系统而直接对数据库数据进行访问？
这种访问方式是否满足公司信息完整性的总体目标？
●管理层针对修改数据访问权限设置（即：
文件读写权限）规定了哪些正式流程？
●对数据的直接访问权限的增加、变更或删除管理层制定了哪些正式流程？
●管理层是否定期审核对数据的直接访问权限（即：
数据库管理员权限），确保权限和员工的岗位职责相符合？
●如果使用了某种特殊工具来实现对数据的直接访问，那么对工具的使用是否有记录？
是否会定期审核这些记录？
●管理层对数据环境中潜在的XX的交易是如何进行适当的监控并保留审计轨迹？
当发现数据环境中潜在的XX的活动时，会采取何种措施？
操作系统安全管理
●是否在操作系统层面评估财务数据的风险？
并设计安全控制以规避风险？
●管理层是否制定了更新操作系统安全参数设置的流程（包括，但不限于：
系统整体安全等级参数、密码参数、开启的服务等）？
●管理层是否制定了增加、变更或删除操作系统访问权限的正式流程？
●管理层是否定期审核安全参数设置和操作系统访问权限？
●管理层在操作系统中潜在的XX的交易是如何进行
升级会员 