应用系统采购、开发与实施

一、测试底稿的用途一、测试底稿的用途 二、测试底稿的组成二、测试底稿的组成 三、测试底稿填写说明三、测试底稿填写说明 1.主表填写说明1.主表填写说明 O列：控制类型O列：控制类型 选择该控制活动的控制类型是“预防性控制”或“检查性控制”之一填列。 P列：自动或手工控制P列：自动或手工控制 选择该控制活动的执行方式是“手工控制”或“自动控制”之一填列。 T列：实际执行的控制活动T列：实际执行的控制活动 是指推广公司本地化的控制活动描述 Z列：测试工作底稿索引Z列：测试工作底稿索引 用户在此建立超链接，建立与副表针对该控制活动的测试底稿的勾稽关系。 AA列：第一轮集团项目组测试执行人AA列：第一轮集团项目组测试执行人 填写集团项目组执行该控制活动测试人员名字。 AD列：第一轮集团项目组实施测试日期AD列：第一轮集团项目组实施测试日期 在该列填写第一轮集团项目组实际执行测试的日期。在该列填写第一轮集团项目组实际执行测试的日期。 AE列：第二轮集团项目组测试执行人AE列：第二轮集团项目组测试执行人 填写集团项目组执行该控制活动测试人员名字填写集团项目组执行该控制活动测试人员名字 AH列：第二轮集团项目组实施测试日期AH列：第二轮集团项目组实施测试日期 指集团项目组第二轮测试实际执行测试的日期。 测试底稿填写说明测试底稿填写说明 一、测试底稿的用途一、测试底稿的用途 此测试底稿的用途在于记述XXX企业股份有限公司以及各一线公司，在所有影响关键财务报表科目/ 注释的业务流程的符合性测试的结果。 二、测试底稿的组成二、测试底稿的组成 合并版测试底稿包括两类表格: 主表：按照子流程设置，每一子流程对应一个主表，每个主表包括标准控制活动与推广公司实际执 行控制活动。如果标准控制活动在推广公司对应多个实际执行的控制活动，则按实际情况分别描 述，在控制活动编号后加小号（x，x从1开始，为不同情况的描述）。如信息系统基本控制中，在 推广公司是对不同的应用系统有2种不同的备份策略，附表只有一张控制活动GCI1，附表中填写 控制活动情况为GCI11，GCI12） 副表：按照标准控制活动设置，每一个标准控制活动（即使对应多个实际执行的控制活动）设置1张 副表，即REA2代表（房地产销售及收款流程）销售定价子流程中的第二个控制活动的测试底稿 三、测试底稿填写说明三、测试底稿填写说明 1.主表填写说明1.主表填写说明 主表包括表头和表体两部分：表头的填写与控制矩阵的表头相同 A列：控制目标编号A列：控制目标编号 目前我们采用的控制目标编码规则为： 编码格式：流程英文简称CO-子流程编号-控制目标编号 各流称英文简称分别为：房地产销售及收款（RE），人力资源（HR），财务报告（FR），采购及成 本（PC），融资与支付（TR），投资（IN），固定资产（FA），信息系统基本控制（GC），公司层 面控制（CE，RA，CA，IC，M），信息披露（ID） 子流程编号从A开始，如融资与支付有3个子流程，最后的子流程编号应为C 控制目标编号从1开始，如融资与支付第二个子流程中有5个控制目标，其最后的控制目标编号应为5 （TRCOB5）。请注意，控制目标与控制活动不是1对1的关系。 B列：控制目标B列：控制目标 控制目标是指内部控制总体目标在各个业务流程中的具体反映，主要关注的是与财务报表相关的内 部控制。 因此本列的控制目标是以每一个业务流程下的子流程为范围（具体化）、以财务报表认定的5个要素 为指导（与财务相关）而确定的。 控制目标示例： 所有折旧费用被记录在恰当会计期间 薪资的支付经过恰当的审批 所有验收入库的货物均已准确入账 C列：财务报表认定C列：财务报表认定 财务报告认定包括以下5类认定： 完整性(C) 存在或发生(E) 表达与披露(D) 权利与义务(R) 估计或分摊(V) 用户无须对此进行修改，在填写认定时，以缩写字母表示即可。同一控制目标可以有多个财务报表 认定。 D列：对控制目标的解释D列：对控制目标的解释 对控制目标进行定义，以便于模板使用者理解控制目标的具体含义。用户无须对此进行修改。 对控制目标的解释有两种方式：一种是结合风险和业务模块对目标进行的详细解释（这种目标本身 就比较具体，难以进一步解释），一种是对词义的简单解释而把风险和业务模块的内容在“风险” 栏中列示（这种目标一般比较原则，需要进一步解释）。 举例如下： A1应收帐款的回收被及时监控：是指公司通过建立适当的监测手段或应收账款帐龄分析等方法，对 应收账款可收回性进行监控。审批权限、系统权限、岗位职责清晰划分。 A2存货保管具有足够的安全措施：存货存放在有充分安全条件的环境，仓库具有充分的安保设施， 对接触存货人员进行限制 B1所有折旧费用被记录在恰当的会计期间：包含两层含义，首先是指所有的折旧费用都被计提和记 录，其次是这些费用被及时地记录在恰当的会计期间，如新增资产当月不计提折旧。 B2所有的分录在关帐之前都经过审核和记账：要有相应的控制活动控制本会计期间已录入的会计凭 证在关账前都经过审核和记账，目的是保证财务报表信息的完整性。 E列：与控制目标对应的风险E列：与控制目标对应的风险 风险是指在某一特定环境下，在某一特定时间段内，某种损失发生的可能性。换句话说，是在某一 个特定时间段里，人们所期望达到的目标与实际出现的结果之间产生的距离称之为风险。 本列所指的“与控制目标对应的风险”实际是对引起目标不能实现的各个风险因素的分解，因此一 个控制目标可以对应多个风险 在CSOX项目中，风险是指可能导致重要会计科目和披露事项中的重大错报的因素。重要会计科目和 披露事项是透过企业的业务流程/子流程所产生的。若不能有效的透过置于业务流程/子流程的内部 控制以控制有关风险，错报的可能性便会增加。 一项控制目标在流程模块层面可能因风险因素的不同而对应不同的风险，因此本列应该按照业务模 块存面的不同风险因素所产生的风险分别填列。 从审计角度看，风险有如下几类： 固有风险是指假定不存在相关内部控制时，某一账户或交易类别单独或连同其他账户、交易类别产 生重大错报或漏报的可能性。 控制风险是指某一账户或交易类别单独或连同其他账户、交易类别产生错报或漏报，而未能被内部 控制防止、发现或纠正的可能性。 检查风险是指某一账户或交易类别单独或连同其他账户、交易类别产生重大错报或漏报，而未能被 实质性测试发现的可能性。 本列所指的风险应当是固有风险和控制风险，目标和风险可以是一对一也可以是一对多的关系。 F列：标准控制活动编号F列：标准控制活动编号 编码格式：流程英文简称-子流程编号-控制目标编号 各流称英文简称分别为：房地产销售及收款（RE），人力资源（HR），财务报告（FR），采购及成 本（PC），融资与支付（TR），投资（IN），固定资产（FA），信息系统基本控制（GC），公司层 面控制（CE，RA，IC，M），信息披露（ID） 子流程编号从A开始，如融资与支付有3个子流程，最后的子流程编号应为C 控制目标编号从1开始，如融资与支付第二个子流程有7个控制活动，其最后的控制目标编号应为7 （TRB7）。请注意，控制目标与控制活动不是1对1的关系。 G列：适用的公司层级G列：适用的公司层级 是对标准控制活动适用范围的界定 按照控制活动适用的公司层级选择填写“集团”（此处的集团概念包含“区域本部”）、“一线公 司”、“全部适用”，每一控制活动可能适用于不止一个层级的公司。 H列：标准控制活动名称H列：标准控制活动名称 是对标准控制活动的高度概括，方便管理层全面快速了解有关的控制活动。只需在控制矩阵里填 列，在流程描述里不需要体现 有两种命名方式，建议合并使用： 以概括性的语言命名，例如：使用部门经理核实增减变动的准确性（使用部门和资产专业部门在资 产情况发生增减变动时具体业务经办人员通过系统或以纸质凭证提交本部门其他独立人员复核后传 递给财务部门以保证计提折旧所依赖的原始信息的准确性） 以关键控制点命名，例如：会计复核与稽核（财务部资产管理会计每月月末根据系统自动生成的累 计折旧汇总表或系统直接导入数据编制或生成固定资产折旧凭证，经复核后打印出会计凭证，会计 稽核人员对会计凭证审核签字并更新明细帐和总帐） I列：标准控制活动描述I列：标准控制活动描述 一般来说，一个风险因素要对应一个或一个以上的控制活动。用户需要根据业务流程的实际情况， 描述其当前实际存在的控制活动。控制活动的描述要全面详细、语言精炼，一般要求在控制活动中 明确出“谁执行, 执行什么活动, 何时执行, 在哪里执行, 如何执行，执行频率”等信息。 如果一个风险因素存在多个控制活动，用户可自行在控制矩阵中添加行用于放置新的控制活动。 标准控制活动的基本类型 1.授权审批控制(Authorization) 2.异常报告、文档编辑记录控制（Exception/Edit report） 3.数据传递、数据转换控制（Interface/Conversion controls） 4.业绩考核指标（Key performance indicator） 5.独立复核控制（Management review） 6.核对控制（Reconciliation） 7.职责分离控制（Segregation of duties） 8.系统接触控制（System access） 9.系统设置、会计科目的系统设置（Configuration/Account mapping controls） J列：信息处理目标J列：信息处理目标 信息处理目标CAVR 用来评估内控设计的有效性，尤其是业务流程中的应用控制。 信息处理目标包括以下4类认定： 完整性(C) 准确性(A) 真实性(V) 访问安全性(R) 用户无须对此进行修改，在填写认定时，以缩写字母表示即可。同一控制目标可以有多个信息处理 目标。 如果该控制活动还在一定程度上满足公司反舞弊的要求，在该列除了填列相关的信息处理目标认定 K列：与财务报表相关的科目K列：与财务报表相关的科目 是指直接和主要影响的报表科目 将各业务流程中的控制活动与可能影响的财务报表科目建立对应关系。 某个控制活动可能同时影响多个财务报表科目； 某个财务报表科目也可能受到多个控制活动的控制： 有些控制活动也可能不直接影响财务报表科目。 L列：风险评级L列：风险评级 本列是指风险因素层面的评级，既可以是定性的（指产生风险的可能性、依据主观判断），也可以 是定量的（指造成报表错报金额的大小，通过计算确定），主要依赖定性的评级方式。风险评级应 当在下拉菜单中选择“高”、“中”、“低”三者之一填列。 M列：控制的重要性M列：控制的重要性 判断该控制活动是否为关键控制活动，在表格中进行选择。如果该控制活动对应的风险评级为“高 ”或“中”的，该列请选“关键控制”；否则请选“一般控制”。 N列：执行频率N列：执行频率 选择该控制活动的执行频率，该部分将用于测试阶段样本量的计算。执行频率应当在下拉菜单中选 择“每日多次”、“每日”、“每周”、“每月”、“每季”、 “每半年”、“每年”、“业务发 生时”之一填列。 O列：控制类型O列：控制类型 选择该控制活动的控制类型是“预防性控制”或“检查性控制”之一填列。 P列：自动或手工控制P列：自动或手工控制 选择该控制活动的执行方式是“手工控制”或“自动控制”之一填列。 Q列：测试方法Q列：测试方法 在下拉菜单中选择，四个选项之间有包含关系，询问最低；观察包含询问；检查包含观察和询问； 重新执行最高包含前三项。通常情况下该列已经填写好，无特殊情况不需修改。副表中的测试程序 也对其进行了具体解释。 R列：标准控制活动样本量R列：标准控制活动样本量 对应主表N列的标准控制活动的执行频率填写标准的样本量。对于执行频率为业务发生时的标准控制 活动，可在样本量一列中填写“根据预计全年发生数量按照抽样标准确定样本量”。 S列：实际执行控制活动编号S列：实际执行控制活动编号 是指推广公司需要填列的控制活动编号 如果该标准控制在推广公司不适用，请在该该单元格填列“N/A“，同行内本单元格后其余列为空。 T列：实际执行的控制活动T列：实际执行的控制活动 是指推广公司本地化的控制活动描述 U列：与财务报表相关的科目U列：与财务报表相关的科目 填列直接和主要影响推广公司报表的科目 将各业务流程中的控制活动与可能影响的财务报表科目建立对应关系； 某个控制活动可能同时影响多个财务报表科目； 某个财务报表科目也可能受到多个控制活动的控制： 有些控制活动也可能不直接影响财务报表科目。 V列：执行频率V列：执行频率 是指推广公司本地化控制活动的执行频率 选择该控制活动的执行频率，该部分将用于测试阶段样本量的计算。执行频率应当在下拉菜单中选 择“每日多次”、“每日”、“每周”、“每月”、“每季”、 “每半年”、“每年”、“业务发 生时”之一填列。 W列：控制类型W列：控制类型 是指推广公司本地化控制活动的控制类型 选择该控制活动的控制类型是“预防性控制”或“检查性控制”之一填列。 X列：自动或手工控制X列：自动或手工控制 针对推广公司本地化控制活动 选择该控制活动的执行方式是“手工控制”或“自动控制”之一填列。 Y列：控制活动负责人/相关部门Y列：控制活动负责人/相关部门 为控制活动的相关部门或人员，一般为该控制活动的复核人或执行人。 Z列：测试工作底稿索引Z列：测试工作底稿索引 用户在此建立超链接，建立与副表针对该控制活动的测试底稿的勾稽关系。 AA列：第一轮集团项目组测试执行人AA列：第一轮集团项目组测试执行人 填写集团项目组执行该控制活动测试人员名字。 AB列：第一轮集团项目组测试执行人所在的公司、部门和岗位AB列：第一轮集团项目组测试执行人所在的公司、部门和岗位 在该列中填写集团项目组测试执行人所在的公司和任职的岗位。在该列中填写集团项目组测试执行人所在的公司和任职的岗位。 XXX方人员填写：XXX顾问XXX方人员填写：XXX顾问 XXX方人员填写：XXX集团XXX部门XXX岗（如：XXX集团财务管理部XX岗）XXX方人员填写：XXX集团XXX部门XXX岗（如：XXX集团财务管理部XX岗） XXXXXXXX部门XXX岗（如：深圳XXX财务管理部XX岗） XXXXXXXX部门XXX岗（如：深圳XXX财务管理部XX岗） AC列：第一轮集团项目组测试评价AC列：第一轮集团项目组测试评价 用户在此建立超链接，建立与副表备注栏中“第一轮测试结果评价”的勾稽关系。用户在此建立超链接，建立与副表备注栏中“第一轮测试结果评价”的勾稽关系。 AD列：第一轮集团项目组实施测试日期AD列：第一轮集团项目组实施测试日期 在该列填写第一轮集团项目组实际执行测试的日期。在该列填写第一轮集团项目组实际执行测试的日期。 AE列：第二轮集团项目组测试执行人AE列：第二轮集团项目组测试执行人 填写集团项目组执行该控制活动测试人员名字填写集团项目组执行该控制活动测试人员名字 AF列：第二轮集团项目组测试执行人所在的公司、部门和岗位AF列：第二轮集团项目组测试执行人所在的公司、部门和岗位 在该列中填写集团项目组测试执行人所在的公司和任职的岗位。在该列中填写集团项目组测试执行人所在的公司和任职的岗位。 XXX方人员填写：XXX顾问XXX方人员填写：XXX顾问 XXX方人员填写：XXXXXXXX部门XXX岗（如：成都XXX人力资源部XX岗）XXX方人员填写：XXXXXXXX部门XXX岗（如：成都XXX人力资源部XX岗） AG列：两轮测试总体测试结果评价结果AG列：两轮测试总体测试结果评价结果 用户在此建立超链接，建立与副表备注栏中“两轮测试总体评价结果”的勾稽关系用户在此建立超链接，建立与副表备注栏中“两轮测试总体评价结果”的勾稽关系 AH列：第二轮集团项目组实施测试日期AH列：第二轮集团项目组实施测试日期 指集团项目组第二轮测试实际执行测试的日期。 2.副表填写说明副表填写说明 副表表头命名：根据标准控制活动编号命名，如标准控制活动HRA1的表单命名为HRA1。 控制活动和控制活动编号：与主表保持一致。 副表表体填写说明： 业务现状业务现状 由集团项目组测试人员填写。根据当地更新后的控制矩阵填写 填列对应该标准控制活动的所有实际执行的控制活动，包括自动控制和手工控制活动。要分别标明 多个实际执行的控制活动的编号，如： HRA11:XXXXXXXXXX。 HRA12:XXXXXXXXXX。 注：在填写测试底稿时，应将多余的行次，以及多余的控制活动编号删除。 比如标准模板中设计了REB31:XXX REB32:XXX。 而本地实际控制活动只有一个REB3:XXX。那么，需要将REB32删除，同时也要将REB3 1中的“1“删除，以保持前后一致性。 总样本量总样本量 集团项目组测试人员填写。总样本量为全年样本量总样本量为全年样本量 （1）对于非固定频率的控制活动，需在第二轮测试时重新对总样本量进行评估。（1）对于非固定频率的控制活动，需在第二轮测试时重新对总样本量进行评估。 （2）对于不适用的控制活动，需重新评估不适用的控制活动在第二轮测试期间该活动是否仍为不（2）对于不适用的控制活动，需重新评估不适用的控制活动在第二轮测试期间该活动是否仍为不 适用，如变为适用，则需重新对总样本量进行评估。适用，如变为适用，则需重新对总样本量进行评估。 根据测试手册中样本量相关规定和该控制活动执行频率确定。 如果一个标准控制活动对应多个实际执行的控制活动，要按照测试手册的要求，计算样本量，分别 写明实际执行的每个控制活动对应的样本量。如： RE-A-1-1：XX； RE-A-1-2：XX； 截止上次测试累计有效样本量截止上次测试累计有效样本量 由集团项目组测试人员填写。 可自第一轮测试的工作底稿或“测试结果汇总表”中查出，用于与“总样本量”相结合确定本次需 要抽取的样本量。 如果一个标准控制活动对应多个实际执行的控制活动，要分别写明实际执行的每个控制活动对应的 样本量。如： RE-A-1-1：2； RE-A-1-2：1； 说明：截止上次测试累计有效样本量为“0”，需在第二轮测试中应按照全部样本量从控制活动开始 执行日或整改完成后抽取样本。包括下述两种情况： （1）上次测试中本地化控制活动测试结果是未达标、未发生交易 （2）上次测试的本地化控制活动为不适用，但在第二轮测试时对不适用的的控制活动重新进行评估 后变为”适用”的情况下。 截止第二轮测试，第一轮测试累计有效样本量第二轮测试的样本量全年总样本量。 具体测试方法具体测试方法 原则上采用已设计好的标准测试方法，根据本地化情况对样本量进行适当调整；在标准测试方法不 适用时，在征求集团项目组专业流程组的意见后，可对测试方法进行适当修订，修订后的测试方法 需要由集团项目组相关专业流程组审核。 样本描述样本描述 由集团项目组测试人员填写。 （1）对抽到的样本进行详细描述，使独立的第三方能够根据描述准确发现该样本，以重新执行该测 试，样本描述应具有唯一指定性。描述例如：K2操作系统日志（2007年7月）。 对于一个标准控制活动对应多个实际执行的控制活动的情况，要分别实际执行的控制活动描述样 本，在样本具体描述上方插入一行写明实际执行的控制活动编号. （2）样本描述中体现第一轮测试样本和第二轮测试样本。 如果第一轮测试结果是“未达标”，则不用将第一轮测试底稿中的样本复制粘贴至第二轮测试底稿 中。即删除副表中的所有第一轮测试样本。在第二轮测试中抽取全年样本量。 如果第一轮测试结果是“达标”、“样本量不足”，则在将第一轮测试底稿中的样本复制粘贴至第 二轮测试底稿中。 样本测试结果的选择样本测试结果的选择 在B、C、D、E、F五列对应样本描述的单元格中，需要打开下拉菜单分别选择“达标”、“未达标” 、“不适用”和“未发生交易”。 当某实际执行的控制活动在测试本期间内未发生交易或不适用时，不用填写样本描述与各测试属性当某实际执行的控制活动在测试本期间内未发生交易或不适用时，不用填写样本描述与各测试属性 的测试结果，直接在备注栏中填写测试结果。的测试结果，直接在备注栏中填写测试结果。 测试属性测试属性 原则上采用已设计好的标准测试属性；在标准测试属性不适用时，在征求集团项目组专业流程组的 意见后，可对测试属性进行适当修订，修订后的测试属性需要由集团项目组相关专业流程组审核。 样本属性解释样本属性解释 不同的测试样本，对各测试属性会有不同的判断结果。为方便测试结果使用者能清楚理解测试属性不同的测试样本，对各测试属性会有不同的判断结果。为方便测试结果使用者能清楚理解测试属性 判断结果的的原因，对测试过程中，对个别测试样本判断为“不达标”、“不适用”或特殊情况下判断结果的的原因，对测试过程中，对个别测试样本判断为“不达标”、“不适用”或特殊情况下 判断为“达标”的情况，可在此处进行说明。判断为“达标”的情况，可在此处进行说明。 注：各专业流程组结合本组实际专业流程情况，在各组制定的测试指导说明中予以详细说明解释。注：各专业流程组结合本组实际专业流程情况，在各组制定的测试指导说明中予以详细说明解释。 未达标样本索引未达标样本索引 对于抽取的不合格的样本，建立与未达标样本底稿的索引关系。具体编号原则参照未达标样本编号对于抽取的不合格的样本，建立与未达标样本底稿的索引关系。具体编号原则参照未达标样本编号 规则填写。规则填写。 未达标率未达标率 达标、未达标、不适用、达标率都由内置公式进行自动测算。在新增测试属性时，必须从已有的公 式拷贝到相关的单元格中，并检查公式是否正确。 备注栏中：第一轮测试结果评价备注栏中：第一轮测试结果评价 在下拉菜单中选择达标、未达标、不适用、未发生交易、样本量不足和无法评价的测试评价。注意在下拉菜单中选择达标、未达标、不适用、未发生交易、样本量不足和无法评价的测试评价。注意 此处与主页面中AC列有自动链接关系。此处与主页面中AC列有自动链接关系。 注：对列表选项中选择“无法评价”的情况：注：对列表选项中选择“无法评价”的情况： 一、某些控制活动属性变更（指实质性变更，如果仅是语言描述的修改细化，或属性的简单合并不一、某些控制活动属性变更（指实质性变更，如果仅是语言描述的修改细化，或属性的简单合并不 在变更范围内），导致需对变化的属性进行补测。则此处选项选择“无法评价”。在变更范围内），导致需对变化的属性进行补测。则此处选项选择“无法评价”。 第二轮测试中对于某些控制活动属性变更导致需对变化的属性进行补测，我们遵循原则：从2007年第二轮测试中对于某些控制活动属性变更导致需对变化的属性进行补测，我们遵循原则：从2007年 1月1日起或者整改完毕日起进行补测。如果第一轮测试中的样本描述清晰具有唯一性，补测属性时1月1日起或者整改完毕日起进行补测。如果第一轮测试中的样本描述清晰具有唯一性，补测属性时 可以继续使用原样本；反之，可不采用原样本，从1月1日或整改完毕日到第二轮测试期间抽取样本可以继续使用原样本；反之，可不采用原样本，从1月1日或整改完毕日到第二轮测试期间抽取样本 。 二、由于受系统变更影响，或者业务流程变更导致控制活动发生实质性变化的控制活动，使得第一二、由于受系统变更影响，或者业务流程变更导致控制活动发生实质性变化的控制活动，使得第一 备注栏中：两轮测试总体测试结果评价结果备注栏中：两轮测试总体测试结果评价结果 对两轮测试结果的总体评价，与主表中AG列有自动链接关系对两轮测试结果的总体评价，与主表中AG列有自动链接关系 副表中在下拉菜单中选择达标、未达标、不适用、未发生交易和样本量不足的测试评价，该测试为副表中在下拉菜单中选择达标、未达标、不适用、未发生交易和样本量不足的测试评价，该测试为 发现式抽样，一旦副表中出现某实际执行的控制活动的某个单项属性未达标，主表中该控制活动即发现式抽样，一旦副表中出现某实际执行的控制活动的某个单项属性未达标，主表中该控制活动即 为未达标，所有实际执行的控制活动的所有测试属性都达标且样本量足够的情况下，测试结果为达为未达标，所有实际执行的控制活动的所有测试属性都达标且样本量足够的情况下，测试结果为达 标；“样本量不足”表示本期所抽取的样本量不足，而已经抽取到的样本经过测试，均为达标。标；“样本量不足”表示本期所抽取的样本量不足，而已经抽取到的样本经过测试，均为达标。 当一个标准控制活动对应若干个本地化控制活动，而每个本地化控制活动的测试结果各不相同时，当一个标准控制活动对应若干个本地化控制活动，而每个本地化控制活动的测试结果各不相同时， 由于只能在“主表”中选择一个测试结果，测试结果的选择顺序为：由于只能在“主表”中选择一个测试结果，测试结果的选择顺序为： 未达标未达标 样本量不足样本量不足 达标达标 未发生交易未发生交易 注：当一个标准控制活动对应的若干本地化控制活动测试结果分别为“未发生交易”和“达标”，注：当一个标准控制活动对应的若干本地化控制活动测试结果分别为“未发生交易”和“达标”， 此时两轮测试结果的最终评价结果为“达标”。但由于第二轮测试截止时间尚未到12月31日，因此此时两轮测试结果的最终评价结果为“达标”。但由于第二轮测试截止时间尚未到12月31日，因此 在第三轮测试时，仍应对未发生交易的控制活动再次进行评估。在第三轮测试时，仍应对未发生交易的控制活动再次进行评估。 备注备注 备注项用于填写测试执行人认为重要的补充说明事项，一般应填入备注的事项为： （1）开始执行日：填写实际执行的控制活动在本年度的开始执行的日期或完成整改的日期。 （2）测试结果：根据两轮测试后抽取的样本判断每个实际执行的控制活动的最终测试结果。 （3）说明项目：将对测试结果说明分为如下类型： a.开始执行日说明：因系统变更、业务流程变更、整改原因等其他情况，应重新评估开始执行日， 并对其进行具体说明。 b.测试结果说明：对除“达标”以外的其他测试结果（即未达标、样本量不足、不适用、未发生交 易），均需详细说明原因。 注：对测试结果为“达标”，但有需要特别说明的情况，也可以在进行说明。 c.非固定频率样本量计算说明：非固定频率样本计算的说明要清晰。 注：对于某个控制活动的发生频率是固定的，但每个周期多次发生的现象，如测试手册中列举的银 行余额调节表编制。此类情况下也需要对样本量计算进行说明。 d.其他说明。 上述这些说明，可根据实际测试情况，可多项选择说明项目。 其他说明其他说明 副表会因为具体控制活动的差别而需要增加或修改，对于内容修改、需要增加行或列的情况需要注 意以下事项： （1）内容修改：主表表头内容需要根据推广时的控制活动进行修改，业务现状据实反映，即控制矩 阵中实际执行的控制活动； （2）增加行：需要增加样本时，需要在样本行中间插入，否则内置的公式会失效； 增加列： 需要增加测试属性时，需要在样本列中间插入，否则内置的公式会失效； （3）注意自动链接公式的正确性 （4）测试底稿中不允许插入任何的批注，即“插入批准insert comment“方式。 公司名称：XXX企业股份有限公司（XXX集团）公司名称：XXX企业股份有限公司（XXX集团） 业务流程名称：信息系统基本控制业务流程名称：信息系统基本控制 子流程：应用系统采购、开发与实施子流程：应用系统采购、开发与实施 控制矩阵索引号：XXX集团-8265-应用系统采购、开发与实施控制矩阵索引号：XXX集团-8265-应用系统采购、开发与实施 控制控制 目标目标 编号编号 控制目标控制目标 财务报财务报 表认定表认定 对控制目标对控制目标 的解释的解释 与控制目标对与控制目标对 应的风险应的风险 标准控制标准控制 活动编号活动编号 适用的公适用的公 司层级司层级 标准控制标准控制 活动名称活动名称 标准控制活动描述标准控制活动描述 信息处理目信息处理目 标标 与财务报表相与财务报表相 关的科目关的科目 风险评级风险评级 控制的重要控制的重要 性性 执行频率执行频率 控制类控制类 型型 自动或手自动或手 工控制工控制 测试方法测试方法 标准控制活动标准控制活动 样本量样本量 实际执行控实际执行控 制活动编号制活动编号 实际执行的控制活动实际执行的控制活动 与财务报表相关与财务报表相关 的科目的科目 执行频率执行频率控制类型控制类型 自动或手工自动或手工 控制控制 控制活动负责人控制活动负责人/相相 关部门关部门 测试工作底测试工作底 稿索引稿索引 第一轮集第一轮集 团测试执团测试执 行人行人 第一轮集团测第一轮集团测 试执行人所在试执行人所在 的公司和岗位的公司和岗位 第一轮集第一轮集 团测试评团测试评 价价 第一轮集团实第一轮集团实 施测试日期施测试日期 第二轮集第二轮集 团测试执团测试执 行人行人 第二轮集团测试第二轮集团测试 执行人所在的公执行人所在的公 司和岗位司和岗位 两轮测试两轮测试 总体测试总体测试 结果评价结果评价 结果结果 第二轮集团实第二轮集团实 施测试日期施测试日期 GC-M-1全部适用 应用系统 外包厂商 管理政策 制定 公司必须制定信息系统外包厂商的管理政策，定 期（至少每年一次）或业务需要时复核该政策， 以保证其及时更新。外包厂商管理政策至少包括 以下内容：外包厂商选择的责任人及主要职责； 外包厂商的选择标准、选择流程和规范文档；公 司对外包厂商的内控要求和服务质量要求；对外 包厂商服务的评估体系，包括评估频率、评估方 C，A，V，R所有中中关键控制每年预防性 控制 手工控制检查1GC-M-1集团IT中心在采购信息系统时，根据公司制定 的IT外包管理规定进行。策略的内容包括 外包厂商选择的责任人及主要职责、选择标准 、选择流程和相关规范文档；对外包厂商的内 控要求和服务质量要求；对外包厂商的年度评 估体系（包括评估指标、评估责任部门、评估 表格和评估方法等）。 所有每年预防性控制手工控制GC-M-1 GC-M-2全部适用 管理层批 准新系统 的开发 新应用系统的开发必须经过信息系统管理部门领 导批准以确保符合应用系统开发与实施政策。 C，A，V，R所有中中关键控制业务发生时预防性 控制 手工控制检查根据预计全年发 生数量按照抽样 标准确定样本量 GC-M-2公司应用系统的开发，由需求部门提出立项申 请，填写立项申请表由集团IT中心与应用 系统使用部门对项目的技术可行性、经济可行 性和操作可行性进行充分的分析研究，形成 可行性分析报告。如果可行性分析报告提出 开发的结论，必须集团助理总经理批准，经批 准后才可进行开发。 所有业务发生时预防性控制手工控制GC-M-2#REF!#REF! GC-M-3全部适用 外包厂商 选择具体 执行情况 的检查 外包厂商的选择必须按照公司外包厂商管理政策 执行，对供应商进行评价与选择。 C，A，V，R所有低一般控制业务发生时预防性 控制 手工控制检查根据预计全年发 生数量按照抽样 标准确定样本量 GC-M-3审批通过后，在选择供应商时，集团IT中心协 同业务部门进行评标，列出重要指标，并对供 应商进行评分。集团IT中心对系统平台和技术 的考察，业务部门对供应商管理的评判，共同 编写定标意见表。 所有业务发生时预防性控制手工控制GC-M-3 GC-M-4全部适用 合同管理信息系统管理部门的领导必须按外包管理政策与 供应商签订合同。 R，AF所有低一般控制业务发生时预防性 控制 手工控制检查根据预计全年发 生数量按照抽样 标准确定样本量 GC-M-4应用系统的采购选定供应商后，必须由项目负 责人与供应商沟通确定合同内容，并经过集团 风险管理认可，由集团IT中心和集团风险管理 部通过网上平台进行审批。审批通过后，集团 IT中心打印审批意见书与应用系统采购 合同，提交集团总经理办公室文件管理盖 章，总经理办公室秘书必须核对系统中的审批 编号与审批意见书是否一致。 所有业务发生时预防性控制手工控制GC-M-4 GCCO-GCCO- M-2M-2 第三方服务是 安全、准确和 可用的，并且 能够支持信息 C，E， R，V，D 第三方服务 要签订服务 级协议。 公司存在外包供 应商所提供的服 务不能满足管理 层预期要求的情 GC-M-5全部适用 服务质量 监督 信息系统管理部门的主管必须按外包采购合同审 查外包厂商的服务质量，并定期（至少每年一 次）对外包厂商进行资质评估，以符合公司的信 息系统外包管理政策。 V所有中中关键控制业务发生时检查性 控制 手工控制检查根据预计全年发 生数量按照抽样 标准确定样本量 GC-M-5集团IT中心协同应用系统使用部门每年外包厂 商的服务质量进行评估，填写外包厂商评估 表，按照评估指标评分。外包厂商评估表 作为今后选择外包厂商的重要依据 所有业务发生时检查性控制手工控制GC-M-5#REF!#REF! GC-M-6全部适用 制定应用 系统开发 政策 公司制定统一的应用系统开发及实施政策，定期 （至少每年一次）和业务需要时复核该政策，以 保证其及时更新。该政策内容至少包括：应用系 统开发及实施责任人及主要职责；应用系统开发 与实施的具体流程；公司对应用系统开发与实施 的内控要求和质量要求；应用系统开发与实施中 形成的规范文档及保存。 C，A，V，R所有中中关键控制业务发生时检查性 控制 手工控制检查根据预计全年发 生数量按照抽样 标准确定样本量 GC-M-6集团IT中心负责制定信息系统建设规范， 对开发项目组的成立、人员的组成、开发过程 的标准、信息技术的选择、应用系统开发实施 所必须的职责分离等内控要求和质量要求、文 档的提供和管理等方面进行约定，用于指导公 司的应用系统开发流程。集团IT中心经理于每 年以及重大应用系统开发实施项目结束后复核 该政策，以保证政策及时更新，符合公司业务 所有业务发生时检查性控制手工控制GC-M-6#REF!#REF! GC-M-7全部适用 管理层监 督项目开 发 信息系统开发项目组应该制定规范的应用系统开 发项目进度计划，项目组负责人必须监督开发的 执行情况是否符合项目进度计划，并应该在出现 偏差时出具解决报告。 C，A，V，R所有低一般控制业务发生时检查性 控制 手工控制检查根据预计全年发 生数量按照抽样 标准确定样本量 GC-M-7应用系统开发项目组成立后，由项目组负责人 制定应用系统开发项目计划，包括人员安 排、进度安排和开发工作安排等内容，项目组 负责人负责监督整个项目的开发进程，以保证 符合公司的项目计划，如果开发项目过程中出 现偏差，出具问题解决报告或重新更新项目计 所有业务发生时检查性控制手工控制GC-M-7 GC-M-8全部适用 进行系统 需求分析 信息系统开发项目组必须进行功能性和系统性的 需求分析，同时编写系统需求说明书，需求说明 书必须得到IT和业务需求部门的确认，以符合公 司开发与实施政策要求。 C，A，V，R所有中中关键控制业务发生时检查性 控制 手工控制检查根据预计全年发 生数量按照抽样 标准确定样本量 GC-M-8项目组必须和最终用户、业务需求部门进行充 分交流，收集各种业务需求，明确应用系统的 目标要求、最终用户使用的要求，并认真对需 求进行分析，明确应用系统的功能和性能，确 定同其它应用系统的接口细节等，编写需求 说明书。需求说明书经集团IT中心经理和业 务需求部门主管签字确认。 所有业务发生时检查性控制手工控制GC-M-8#REF!#REF! GC-M-9全部适用 进行系统 设计 信息系统开发项目组应该根据系统需求说明书对 应用系统进行设计，并制定设计文档，以符合公 司开发与实施政策要求。 C，A，V，R所有中中关键控制业务发生时检查性 控制 手工控制检查根据预计全年发 生数量按照抽样 标准确定样本量 GC-M-9公司与外包商共同商议需求和系统架构，决定 应用系统内各模块单元的数据结构、逻辑结构 等设计框架，直至分解到编码层面，由外包公 司开发人员根据提出的设计要求编写程序模 块，独立完成系统。开发商提供系统设计文 所有业务发生时检查性控制手工控制GC-M-9#REF!#REF! GC-M-10全部适用 依照测试 计划测试 测试人员必须依照测试计划进行测试，并出具测 试报告，测试至少包括单元和系统测试、界面和 接口测试、平行测试、容量测试和用户测试。信 息系统开发项目组负责人监控测试计划的执行情 况，并审核测试报告。 C，A，V，R所有高高关键控制业务发生时检查性 控制 手工控制检查根据预计全年发 生数量按照抽样 标准确定样本量 GC-M-10项目组制定应用系统测试计划，包括对测 试需要的事件、资源要求，每项测试活动的内 容、设计考虑、测试用例和测试数据的准备和 评价标准，测试应按具体情况包含单元和系统 测试、界面和接口测试、平行测试、容量测试 及用户测试。测试人员按照测试计划认真执 行，出具应用系统测试报告。项目组负责 人员负责监控测试计划的执行情况，并对测试 报告进行审核，审核测试报告的内容是否符合 所有业务发生时检查性控制手工控制GC-M-10#REF!#REF! GC-M-11全部适用 独立的开 发测试环 境 应用系统应该在与生产环境(系统)相独立的测试 环境中进行开发、修改与测试。 R所有中中关键控制业务发生时预防性 控制 手工控制检查根据预计全年发 生数量按照抽样 标准确定样本量 GC-M-11为了保证应用系统的开发测试不影响生产系统 的正常运行，项目组应该搭建应用系统的测试 环境，确保应用系统的开发、修改与测试在与 生产环境相独立的环境中进行 所有业务发生时预防性控制手工控制GC-M-11#REF!#REF! GC-M-12全部适用 测试数据 的确定 测试人员应该用完整、具代表性的测试数据来测 试系统，而非实际的生产数据。 C，A所有低一般控制业务发生时预防性 控制 手工控制检查根据预计全年发 生数量按照抽样 标准确定样本量 GC-M-12项目组在测试时，使用完整的具有代表性的数 据取代真实数据进行测试，不能使用生产数 据，以免影响生产业务 所有业务发生时预防性控制手工控制GC-M-12 GC-M-13全部适用 测试和生 产环境的 访问 能够进入测试环境与实际生产环境的人员必须被 严格分离。如果需要进入到生产环境，应用系统 开发人员必须在其他信息系统管理人员陪同或监 督下执行操作。 R，AF所有中中关键控制业务发生时预防性 控制 手工控制检查根据预计全年发 生数量按照抽样 标准确定样本量 GC-M-13应用系统的测试环境和生产环境应给予隔离， 应有相应的权限管理，避免非法用户的登陆。 同时如果应用系统开发人员需要进入生产环 境，必须在营运人员监督下进行。 所有业务发生时预防性控制手工控制GC-M-13#REF!#REF! GC-M-14全部适用 独立的测 试人员 测试人员必须与开发人员职责分离。R，AF所有中中关键控制业务发生时预防性 控制 手工控制检查根据预计全年发 生数量按照抽样 标准确定样本量 GC-M-14公司应有相应的权限管理，限制应用系统的测 试人员不能由开发人员担当。 所有业务发生时预防性控制手工控制GC-M-14#REF!#REF! GC-M-15全部适用 开发版本 控制 文档管理员必须对应用系统开发的代码、参数和 文档进行版本管理，并由信息系统开发项目组负 责人复核，以保证上线前后采用的版本一致。 C，A，V，R所有低一般控制业务发生时检查性 控制 手工控制检查根据预计全年发 生数量按照抽样 标准确定样本量 GC-M-15项目组应指派专门文档管理员统一负责对应用 系统开发的代码、参数等进行版本管理，并记 录在变更版本控制记录中，项目组负责人 在系统上线前复核代码和参数等的版本，以确 保应用系统上线版本正确。 所有业务发生时检查性控制手工控制GC-M-15 GC-M-16全部适用 评估开发 变更并经 管理层审 核 信息系统开发项目组应该对应用系统开发实施期 间的变更进行评估，并得到信息系统管理部门主 管领导审核。 C，A，V，R所有低一般控制业务发生时检查性 控制 手工控制检查根据预计全年发 生数量按照抽样 标准确定样本量 GC-M-16应用系统在开发过程中需要进行变更时，项目 组必须对变更申请进行初步评估审核，审核判 断项目变更是否必要。如果认为变更（撤销） 没有必要，则终止流程；只有通过集团IT中心 经理和业务部门领导审批的变更方案才能实施 。 所有业务发生时检查性控制手工控制GC-M-16 GC-M-17全部适用 管理层监 督项目实 施 信息系统开发项目组应该制定规范的应用系统实 施计划，项目组负责人必须监督实施的执行情况 是否符合计划。 V所有低一般控制业务发生时检查性 控制 手工控制检查根据预计全年发 生数量按照抽样 标准确定样本量 GC-M-17任何应用系统的实施，必须经公司主管IT的总 经理批准才能执行。全部开发工作完成以后， 项目组负责应该制定应用系统实施计划， 对割接、试运行、初验、正式运行、终验、后 评估等阶段的活动进行了约定。项目组负责人 应该定期跟踪各相关部门的工作进度，使其进 度与计划保持一致。 所有业务发生时检查性控制手工控制GC-M-17 GC-M-18全部适用 管理层监 督新系统 割接 对于旧系统升级，信息系统开发项目组必须制定 割接方案，明确割接的步骤、负责人、方法等。 V所有中中关键控制业务发生时检查性 控制 手工控制检查根据预计全年发 生数量按照抽样 标准确定样本量 GC-M-18项目组必须制定割接方案，割接方案 的内容应该包括：割接的业务范围说明、时间 安排、步骤、各步骤实施负责人、验证方法等 。方案必须在项目组负责人审批后，按照计划 所有业务发生时检查性控制手工控制GC-M-18#REF!#REF! GC-M-20全部适用 系统试运 行 信息系统管理部门主管领导必须对应用系统上线 试运行的执行人员、时间、地点、方法进行审批 。 V所有低一般控制业务发生时检查性 控制 手工控制检查根据预计全年发 生数量按照抽样 标准确定样本量 GC-M-20项目组制定系统试运行计划，包括试运行 的执行人员、时间、地点和试运行方法和范围 等内容，由集团IT中心经理审批签字。 所有业务发生时检查性控制手工控制GC-M-20 GC-M-21全部适用 对系统实 施验收 公司对系统进行终验，出具并保存验收报告，并 经信息系统管理部门主管领导审批。 V所有低一般控制业务发生时检查性 控制 手工控制检查根据预计全年发 生数量按照抽样 标准确定样本量 GC-M-21系统正式使用在生产环境后，项目经理进行终 验，收集业务部门意见，经过集团IT中心经理 审批后，出具验收报告 所有业务发生时检查性控制手工控制GC-M-21 GC-M-22全部适用 根据实施 计划提供 技术资料 确定的实施计划或政策中应该规定提供操作手册 、技术资料和用户手册使用的流程，实施过程中 信息系统开发项目组负责人监控执行情况。 C，A，V，R所有低一般控制业务发生时检查性 控制 手工控制检查根据