企业信息系统应用控制设计工作程序

曲传祥

摘要

随着企业信息化的深入和与业务深度融合，信息系统风险逐渐转化成了业务风险和企业的经营风险，对企业的经营活动有重大影响。也就要求企业有适当的控制手段，降低信息化所带来的风险，这就需要信息系统应用控制。信息系统应用控制可以提高企业管理水平，减少人为操纵因素；增强信息系统的安全性、可靠性和合理性以及相关信息的保密性、完整性和可用性。

【关键词】企业信息系统 应用控制 设计

信息系统应用控制（Application Controls）包括企业信息系统中的程序化步骤以及用以控制不同种类处理的相关的手工操作程序。这些控制结合一起可以保证信息系统的安全性、完整性、准确性和有效性。结合企业信息系统建设与控制设计的工作实践，信息系统应用控制设计工作程序主要包括以下五个环节：

1系統功能调研

系统功能调研的目的是为了确认应用系统是否纳入应用控制设计范围。在调研过程中，要从信息系统需求分析报告出发，根据原则和标准将信息系统划分为财务关联信息系统和非财务关联信息系统，信息系统应用控制的重点就在财务关联信息系统。以下前三项条件全部满足者为重要关联信息系统，若三项条件不全部满足，则考虑与外围系统的接口情况。

1.1业务重要性判断

按照企业内部管控规范，并结合与财务的关联程度，在各业务领域建立的信息系统开展业务重要性认定。

1.2对财务数据影响程度的判断

对财务数据的影响根据会计科目和财务报告所披露的内容进行判断，分为直接影响和间接影响。直接影响为该系统直接对会计科目产生影响，间接影响为该系统的数据会间接对会计科目产生影响

1.3对系统依赖程度的判断

判断信息系统是否涉及复杂计算、检查及处理过程。在信息系统同时符合以下标准和条件的属于信息系统复杂的计算和处理过程，且无法全部依赖人工操作：

（1）信息系统涉及多个岗位及人员，需多岗位协同操作才能完成一项业务的处理；

（2）信息系统本身含有复杂的计算公式，最终输出结果依赖固化在信息系统中的公式计算获得，如依靠人工计算，则无法应付日常业务操作，且结果不准确的风险非常高。

1.4考虑与已有外围系统接口情况

在判断信息系统是否为财务关联系统时，尽管有部分系统不完全满足上述三条标准，但还应考虑与外围系统接口的影响。信息系统集成度的提高，该条判断标准将会越来越受到关注。

2差异分析

通过分析、讨论，比对分析系统设计（蓝图）和原企业业务流程图业务处理范围、控制要求等，确定控制设计的流程范围、完善系统蓝图控制设计，最终给出系统设计（蓝图）与业务流程对照表、差异分析报告等。对原有业务流程和系统系统设计（蓝图）进行对比，对比的内容包括：处理业务环节是否一致、对财务数据影响（科目）是否一致、业务流程负责部门是否相同。

（1）根据信息系统需求分析说明书或项目设计说明书，逐级建立系统设计（蓝图）与己有业务流程的对应关系。

（2）在己建立系统业务流程与企业业务流程对照关系的基础上，对系统业务流程设计的合理性进行审阅，并出具审阅调整意见。考虑因素包括系统流程信息是否完整、要环节是否缺失、实施证据是否规范完整、系统可否实现审批环节、复核环节、复杂计算环节、指标控制、权限控制环节、相关业务关联环节、权限控制环节等的自动化。

（3）根据系统流程设计及功能设计，完善现有业务流程，将系统设计（蓝图）以业务对照关系为依据融入本单位的业务流程中，从而形成一套完整的适用于信息系统上线单位的业务流程。

3风险分析

风险分析主要从信息处理流程角度进行分析，并将应用控制层面信息系统相关风险分为四类：

3.1输入环节

未有严格的系统录入控制、数据源头、接口数据控制，可能导致进入系统中的数据不准确和不完整。包括录入错误、重复录入、漏记、网络或系统故障导致数据传输失败（包括未传输、传输数据错误、重复传输）、系统间对照关系维护错误导致数据传输失败等情况，导致相关业务数据、财务数据不完整不准确。

3.2处理环节

信息系统处理不正确，例如汇总、过滤、排序、应计、分摊、自动核对、标准应用等处理计算错误，可能导致企业业务不能正常运转，对企业造成重大损失。

处理环节比较复杂，按照风险与信息系统及业务的关联度不同可将风险再细分为信息系统自身引入的风险、信息系统上线导致业务流程变化而引入的新风险或导致原有风险发生变化，以及原有业务未发生变化的风险等三类。

3.3输出环节

信息输出的内容、方式、时间、频度、接收者缺乏控制，可能导致信息重复输出、信息缺乏决策相关性或信息泄密。

输出环节可以是系统本身的报表展示，也可以是通过接口传输，作为其他系统的输入信息。其输出的信息可以是一项业务的最终结果，也可以成为是中间结果，后续还需进行加工处理，但无论是上述哪种情况，输出环节的风险均可划分为信息输出的内容不完整、不准确，存在遗漏或重复输出，以及对信息输出的接收者缺乏控制，可能导致信息泄密。

3.4系统处理授权环节

未执行合理、有效的业务处理环节授权管理，影响数据确性、保密性，并可能导致舞弊行为出现，进而造成企业损失。该环节面临非授权访问、修改系统信息的风险、同时拥有同一业务链条上的多个权限，且利用这些权限可进行舞弊等多种风险。

对上述环节识别出的信息系统相关风险，根据风险评估标准，从风险发生可能性和影响程度两个维度进行分析，确定风险的重要性水平。对于风险评估结果为中高的风险，其对应业务流程为也确认为重要或一般流程，需要进行控制设计；对于风险评估结果为低的风险，不进行应用控制设计，仅根据系统设计（蓝图）完善相应业务流程。endprint

4控制設计

根据风险评估结果开展控制设计，通过系统跟单测试确认控制措施的可行性，整理形成系统风险控制文档。

4.1输入环节控制设计

当采用手工输入方式，一般采取独立于信息录入人员的岗位依据原始单据对系统录入信息进行复核，并签字确认的控制措施，其为依赖于系统的手工控制。该控制措施广泛应用于系统录入环节。当采用系统接口从其他系统自动读取的方式进行信息录入时，需要重点关注系统间数据映射表维护的准确性，该环节主要采取的控制方式为固有控制、自动控制、职责分离控制以及访问控制。对于系统接口应单独进行控制设计，具体应涵盖自动控制、依赖系统的手工控制、职责分离控制、访问控制五个方面。在不同的业务场景下，控制措施应该根据实务进行细化。

4.2处理环节控制设计

处理环节较输入环节更为复杂，其随不同的系统和业务而由较太差异。控制方式与输入环节的设计在原理上是一致的，但是处理环节需要考虑信息系统上线以后，业务处理发生了变化，其控制措施如何更改的情况。新上线系统的控制设计应建立在原有流程和控制的基础上，对系统上线对业务流程和控制的影响进行分析，最终形成整合后的系统控制文档。

4.3输出环节控制设计

输出环节控制一般依赖于系统的固有控制，不单独进行控制设计，在此不做详细的介绍。

4.4系统处理与授权环节控制设计

系统处理与授权环节的控制即信息系统的权限管理，在实际应用中，权限一般分为关键权限和非关键权限，权限管理主要集中在关键权限。

信息系统权限控制设计及管理因遵循以下原则：需求导向及最小授权原则，未明确允许即禁止，职责分离原则。

需求导向及最小授权原则：对于用户的权限，应当以其实际工作需求为依据，且仅应当授予能够完成其工作任务的最小权限。

未明确允许即禁止：除非用户有对于权限的需求得到了相关领导的明确批准，否则不应当授予任何权限。

职责分离原则：对于同一组不相容权限，任何用户不能同时具有两种（或两种以上）的权限。

在对系统处理授权环节进行控制设计时，应首先了解该信息系统权限的设计及分配情况，不同的信息系统在权限设置和管理上可能会形成基于用户、角色、任务的不同分类。

权限管理由访问控制和职责分离两个方面的内容组成：

访问控制：是指用户能够访问哪些应用系统内的资源或执行哪些任务（或功能）的范围，从控制的角度考虑在系统中所拥有的功能权限和数据权限是否超出了其工作需要。访问控制包括三个要素：主体、客体和控制策略。

主体（Subject）是指提出访问资源具体请求。是某一操作动作的发起者，但不一定是动作的执行者，可能是某一用户，也可以是用户启动的进程、服务和设备等。

客体（Object）是指被访问资源的实体。所有可以被操作的信息、资源、对象都可以是客体。客体可以是信息、文件、记录等集合体，也可以是网络上硬件设施、无限通信中的终端，甚至可以包含另外一个客体。

控制策略（Attribution）是主体对客体的相关访问规则集合，即属性集合。访问策略体现了一种授权行为，也是客体对主体某些操作行为的默认。

职责分离：职责分离是把一个业务（子）流程的工作内容分为几个职责不相容的部分并由不同的人来完成，职责分离的两个基本设想为：两个或以上的人或部门无意识地犯同样错误的概率很小；两个或以上的人或部门有意识地合伙舞弊的可能性大大低于单独一个人或部门舞弊的可能性。

职责分离是组织机构安全运作的必要条件，为了在计算信息系统中实现职责分离机制，首先需要在现实世界与计算机系统之间进行良好的映射：现实领域中的工作人员映射为信息系统中的用户，工作人员的工作职责映射为信息系统中用户拥有的权限集，工作人员能执行什么工作职责，用户就执行什么权限集。因此，在给用户分配权限、用户执行权限时，就要注意需要分离的职责在信息系统中所映射的权限集的并集不能由同一个用户同时拥有或执行。

职责分离的实现可以从业务流程的维度和企业组织结构的维度两个纬度进行展开。从业务流程的维度（横向）出发，职责分离涉及的环节包括交易的发起、复核（或授权）、记录、实物保管、稽核检查、主文件维护、系统管理等多个方面。

从企业组织结构的维度（纵向）出发，职责分离包括两个方面：

（1）凡必须由企业组织结构中不同的人完成的职责，也应当视为必须分离的职^

（2）上述权限除第一个层面为录入权限外，其他均为审批权限，各个层级的审批关注点或审批金额有所不同。否则，应考虑管理权限下发，简化业务流程冗余环节。

在实际业务中，往往因为岗位设置、业务特殊性等原因而导致本应互斥的关键权限无法拆分，在此种情况下，首先应判断是否可采取岗位交叉审核、管理权限上移等方式进行调整，如无法调整的情况下，可允许其拥有相应互斥权限，但需增加额外的控制措施（抽查、轮岗等）以降低同一人员同时拥有互斥权限而导致的舞弊风险。

为了保证系统权限分配满足相关控制要求，需要定期进行权限的测试检查，对发现问题及时组织整改。

4.5形成系统控制文档

对初步完成的控制设计还需要与信息、业务相关人员进行确认，同时对于系统测试需通过系统的跟单测试确认控制设计的可行性和适用性。

在完成控制设计和确认的基础上，整理编写相关工作文档，主要包括：系统业务流程目录、系统关键控制文档（含配置清单）、系统权限控制文档。

5控制执行

通过测试检查系统控制的执行情况，验证系统设计的有效性，形成适用于普遍推广应用的控制设计文档，并组织专项培训，确保系统控制的得到严格执行。

一般来说，系统控制的执行应与系统上线同步开始，在系统运行一个月后，具备测试检查所需充足样本量的前提下，开展控制执行情况的测试检查。

参考资料

[1] IT Governance Institute. C0BIT5.1.

[2] 财政部，证监会，审计署，银监会，保监 会.企业内部控制应用指引.

[3] 中国石油天然气集团公司.信息系统内部 控制设计原理及方法研究.

[4] Tuttle B，Vandervelde SD.An empirical examination of CobiT as an internal control framework for information technology. International Journal of Accounting Information Systems. 2007.endprint