1、应用 GAIT 方法为了帮助你应用 GAIT,这一部分分为下表 5 中的几个部分。表 1:应用 GAIT标题 内容 参见GAIT 简介 GAIT 方法的实质 下文记录 GAIT 结果 如何记录 GAIT 结果 第 15 页制定 GAIT 如何为组织制定 GAIT 第 15 页组成 GAIT 评估团队 应用 GAIT 需要哪些小组成员第 15 页GAIT 方法的步骤 应用 GAIT 方法的每一个步骤第 16 页GAIT 简介GAIT 方法检查财务上重要的所有应用程序，以确定每一层中的 ITGC 过程的故障是否会威胁到应用程序关键功能的持续运作。一旦发生故障，GAIT 将仔细识别 ITGC 过程风
2、险和相关的 ITGC 控制目标，这些目标完成时，可以降低风险。COBIT 和其他方法能够识别关键控制点，以确定 ITGC 控制目标。总之，GAIT 方法通过依次询问以下三个问题来指导读者：1哪些具有财务重要性的应用程序的信息技术功能,对于防止/发现重大错报的企业流程关键控制的正常运作是重要的（例如，关键的信息技术功能是什么）？2对每一层的 IT 过程来讲，是否有这样一种可能性，即一个进程故障会引起关键功能的失败间接地表现为重大错报风险？（例如，如果某一层上的进程发生故障，会对关键功能上产生什么影响？它会引起功能失效，以至于有重大错报风险的可能吗？）3如果这样的 ITGC 过程风险存在，相关的信
3、息技术控制目标是什么？（例如，为了确保关键功能的实现，需要达到哪些信息技术控制目标？）例如风险（在应用层的变更管理过程中）：未测试的应用程序变化会导致关键功能失效。控制目标：所有程序变更都要进行适当的测试，并且在运行前对测试结果进行检验和审批。关键控制点：程序变更的测试在一个独立的测试环境下进行。所有测试结果由一名经理检验和审批对所有较大的变更进行使用者测试，且测试结果由一名经理审批。由高级 IT 管理者对突发变更进行检验和审批。记录 GAIT 结果本文提供了两种记录 GAIT 结果的方法：如下所述的 GAIT 矩阵和 GAIT 模板（参见 26 页的“GAIT 模板” ） 。然而，不管选择哪
4、种方法，应该详细记录 GAIT结果，以使检查者理解形成该结果的基本原理。GAIT 矩阵（见下表 6）描述了这个方法，记录具有财务重要性的应用程序的结果。你可以在每个空格中记录对某一层的企业流程关键功能是否存在风险的评估，并识别相关的 IT 控制目标。表 2:空白 GAIT 矩阵层面 变更管理 操作 安全应用层数据层操作系统网络基础制定 GAITGAIT 是灵活的。使用者可以根据专业术语的含义和 IT 控制框架制定步骤。尤其是，使用者可以在 GAIT 矩阵的堆栈中使用自己对 ITGC 过程和标准的定义如添加使用者访问和特权访问到现有的变动管理，运作，安全中。有关堆栈的更多信息，参见“原则 3”。
5、组成 GAIT 评估小组经验表明，企业使用者通常不能完全理解屏幕上的 IT 功能及他们使用的报告，并且 IT 专家也不能完全理解企业流程及其基础。GAIT 评估应当由一个具备企业和 IT 知识的内部控制专家组成的小组进行。GAIT 起初是由商务专家执行的自上而下的、基于风险的一种方法。GAIT 基于对关键 IT 功能的理解，依靠这些功能，可以保证企业流程潜在失败点评估中识别出来的企业流程关键控制点（预防和发现财务重大错报）适当运作。随着 GAIT 评估的进行，访问 IT 基础和 IT 过程的更多技术方面，IT 专家越来越重要。专家应能充分理解和识别关键 IT 功能（包括关键的自动化控制、关键报
6、告和其他功能） 、相关 ITGC 过程中的潜在失败点，以及适当的 ITGC 控制目标和关键控制点。一个完整的小组应该检验和确认 GAIT 评估结果，确保其适当性和合理性。GAIT 方法步骤为了应用 GAIT 方法，应当遵守下列程序中列示的步骤。程序 1：应用 GAIT 方法第一步 识别（必要时核实）关键信息技术的功能。第二步 识别需要测试的 ITGC 的重要应用程序。第三步 识别 ITGC 过程的风险和相关控制目标。这是 GAIT 方法的核心。第四步 识别满足控制目标的关键 ITGC。第五步 由“合适人员”进行检验。更多使用 GAIT 的信息（包括应用方案） ，见 IIA 网站：http:/w
7、ww.theiaa.org步骤 1 识别（必要时核实）关键信息技术的 功能GAIT 方法首先评价关键的人工和自动企业控制点，以及其他关键系统功能。（下表 2 说明本步骤及下一步骤） 。对企业流程进行自上而下的评估，需要先识别这些关键的人工和自动控制点。GAIT 通过确定 GAIT 评估基础的目录，继续这种自上而下的评估过程，并确保所有关键 IT 功能已识别。在步骤 2 中使用此目录去识别具有财务重要性的应用程序，例如，哪些应用程序包括在 404 条款评估和测试的范围之内。图表 2：步骤 1 和 2AS/2 识别控制点，以便及时进行错误或舞弊的预防/发现的测试步骤 1 识别/证实关键 IT 功能
8、步骤 2 识别需要测试的 ITGC（重要）应用程序程序 2：检查关键手动和自动控制点及关键功能1、检查公司财务过程中的关键控制点、主要报告和其他功能，并确定哪些是手动的，哪些是自动的。2、列出所依赖的关键 IT 功能表。这里包括自动控制（见下面的第 3 步）及其他主要的 IT 功能（见下面的第 5 步） 。自动控制点包括：完全自动的控制点（例如，匹配或更新总分类账中的账户）人工控制依赖 1的应用程序功能。这个功能中的错误可能不会被发现（参见 16 页的“关键报告” ） 。这些人工控制有时也称为“混合控制” 。比如，为发现重复接收的关键控制可能包括检查系统报告。控制的人工部分应当能够发现报告中的
9、错误，但无法保证报告的完整性。因此，关键报告应该确定一个范围。相反，银行余额调节表可能需要使用企业总分类账系统中的报告，显示当前余额、收入及支出。然而，余额调节控制的正常运作会及时发现报告中的错误。所以控制的自动部分不是关键，人工部分才是关键。3、确定关键的自动控制点：检查自动控制点，确保这些控制点是关键的 2。由不同部门识别人工和自动过程中的风险和相关控制的组织，尤其是使用清单或其他自上而下方法的组织，可能把本不是关键控制的自动控制点作为关键控制点。 如果自动控制失败，评估是否至少存在一个重大错误没有被发现的可能性。有时，一些人工关键控制可以在导致重大错误之前察觉自动控制的失败，或发现对重要
10、数据的未授权变更。这些人工控制点应确认为关键控制点，并且将这些自动控制点从关键控制点目录中删去。4、确定在应用程序中是否还有其他关键 IT 功能没有被确认为关键控制，这可能导致故障没有被发现，从而发生财务报表的重大错报。许多进行计算和依靠财务事项过程和相关会计记录的应用程序 3没有严格的控制（参见附录的1ISACA 的萨奥法案的 IT 控制目标描述其为“依赖 IT 的人工控制”或“混合控制” 。2在权衡可靠性和进行人工和自动控制测试时，需要考虑总成本。有人认为自动控制比人工控制更有效，更节约成本。理由是人工控制需要抽取较多样本进行测试，成本较高，而自动控制仅需测试一次。然而，后者假定 ITGC
11、 是有效的，保证自动控制持续运作，样本量可以为 1。依靠自动控制的成本包括评估和测试相关 IT 常规控制过程的关键控制点的成本。许多组织可能更多地受益于自动控制，如何决策应当谨慎，考虑所有成本和涉及的风险。即使自动控制是关键控制，在评估与自动控制有关的 IT 常规控制过程风险时，人工关键控制也会有价值。“控制”定义） 。然而，如果功能失效，关键的人工或自动控制都不能发现重大错误。因此，你需要将任何这样的程序包括进来，作为关键功能，并考虑其风险。因此，应当确认所有的关键 IT 功能为具有财务重要性的应用程序。步骤 2：识别需要测试的 ITGC 的 重要 应用程序一旦确定了关键 IT 功能，就能识
12、别出具有财务重要性的应用程序。具有财务重要性的应用程序是具有潜在 ITGC 过程风险的程序，因为它们包含关键 IT功能或数据（参见附录的专有名词） 。财务事项过程中的应用程序不包括关键 IT 功能和未经授权变更的数据（可能导致重大错误）不在 404 条款的范围之内；相关的 ITGC 不需要测试。程序 3：识别需要测试的 ITGC 应用程序1、根据应用程序对关键 IT 功能进行分类。具有重要功能的应用程序结果列表是将要评估 ITGC 过程风险的具有财务重要性的应用程序列表。2、对基于关键 IT 功能的财务上不是很重要的应用程序，这是一个附加步骤。该步骤评估直接对应用程序数据进行未授权的修改，是否
13、会导致不能发现的重大错误(参见“原则 1”)。该步骤确定数据的修改是否绕过正常的程序和控制（有时称为“走后门” ） ，是否导致正常的控制程序不能发现的财务上的重大错误。如果可能，应当使用 GAIT，把应用程序作为具有财务重要性的应用程序来评估。如果不行，则该应用软件不在考虑范围之内。应该注意，有些计算和其他功能使用在优先程序中生成的数据。数据的修改会导致不能发现的重大错误，这种风险可能不仅存在于使用数据的应用程序，而且还存在于其他程序中（例如，生成数据的应用程序及任何其他存储数据的程序，因此具有风险） 。如果在这里没有发现对数据进行的修改，那么那些上游程序可以认为在财务上很重要。3、具有财务重
14、要性的应用程序继续要点：如果应用程序中不存在以下内容，那么，它在财务上不重要，且不能信赖ITGC：a.关键自动（程序）控制b.关键报告或其他混合控制（依靠 IT 功能、屏幕、报告等的人工控制） c.其他关键 IT 功能d.能够导致关键控制失败（可以影响下游控制）或其他重大错误的数据修改（即便只是掠过） 。这些数据可以是处理数据或参考数据（例如，价格、信用额度等） 步骤 3 识别 ITGC 过程的风险和相关控制目标 。该步骤主要有两件事：3 有些 IT 审计师使用“设定的程序”或“设定的会计程序”进行计算，分类账更新等。获取每个重要应用程序的其他信息评估每个重要应用程序的 ITGC 过程风险：每
15、层的 ITGC 过程下图说明该步骤是如何适应 GAIT 的。 图 3：步骤 3第二步 识别需要测试的 ITGC 的重要应用程序第三步 识别 ITGC 过程的风险和相关控制目标第四步 识别满足控制目标的关键 ITGC在自上而下过程中面向企业流程的部分，你会对财务信息处理的每个应用程序有一个广泛的理解。该步骤要识别企业流程中需要测试的适当控制。完成相关 ITGC 过程的每个重要应用程序的风险评估，通常需要其他信息。 程序 4：拓展对范围内的应用程序及其基础的理解完成 GAIT 评估所需要的信息分为三类：应用程序基础、相关 ITGC 过程和风险指标。表 3:附加应用软件基础构造和风险信息类别 内容应
16、用程序基础 理解和评估应用程序堆栈每一层风险的典型信息如下：支持应用程序的基础要素（例如，数据库、操作系统、网络和数据中心）自动控制是结构设置而非应用程序代码的结果的程度使用的数据库技术。理解其性质和数据库要素变化的频率，如数据库模式，这对关键的自动控制十分重要操作系统（例如，应用程序使用什么操作系统，变化频率如何）重要界面及其人工控制。如果它们未被列为关键控制，你需要将其添加到关键自动控制的列表中，如果其故障没有被正常的关键控制发现，就有可能导致重大错误。网络基础及其潜在失败点（例如，应用程序及其关键自动控制需要依靠网络的传递，网络失败或网络安全缺口极有可能导致财务报表中存在未能发现的重大错
17、误）应用软件是自己研发的，还是购买的？应用软件由自己维护，还是外包？如何支持应用软件及其基础：主要是通过共享服务器还是企业各部门独占服务器？数据中心是由自己运作，还是外包？哪些网络和技术基础运作由自己运作，哪些外包？IT 是如何组织的？它的关键功能是相互独立的吗？风险指标 某些指标在 IT 过程中显示高风险。评估风险时应考虑以下方面：404 条款测试前期或内部审计期间有多少关键控制失效？是哪些关键控制？应用软件的寿命是多少？多久进行一次修正？程序或数据有已知的问题吗？财务上重要的任何应用程序功能有已知的问题吗？购买的应用软件在多大程度上进行了修正、定制和安装？高优先级变更要求的存储是什么？程序
18、问题发生的频率？突发变化发生的频率？关键职位上的员工流动水平是多少？员工有多少经验，以及他们接受过足够的培训吗？GAIT 评估的核心现在开始。对于每个具有财务重要性的应用程序，GAIT 经过堆栈的每一层中的每一个 IT 过程，并且识别 IT 过程风险和相关控制目标。与企业流程中的风险相比，评估这一水平上的风险的挑战，就是 ITGC 过程仅与财务报表间接相关。在 GAIT 中，IT 过程风险的评估是基于关键 IT 功能适当运作的风险的。影响风险评估的另一个因素是，相对于一般企业流程的失败，ITGC 过程中的许多失败更有可能是作为正常运行的一部分被发现。例如，如果安全措施失效，蠕虫或病毒侵入网络，
19、很有可能立刻显示并使其影响最小化。因此，事件发生就存在风险。然而，如果事件的性质是会被及时发现，没有及时发现关键功能失败的风险极小因此，这不可能成为发生财务报表重大错误的原因。评估风险应考虑：IT 过程发生失败的可能性及其潜在影响。这项评估中包括以下几个步骤： 在引起关键 IT 功能失效的方式下，IT 程序失败的可能性有多大？ 关键功能失效没有被及时发现、从而导致财务报表出现重大错误，这可能吗？404 条款的目的，主要是在可能导致（通过影响关键 IT 功能）重大错误，而非任何错误的 IT 程序失败上。包括仅在理论上可能但不可行的 IT 程序风险，也会导致 404 条款的范围无效。 错误是舞弊（
20、目的是欺诈或其他破坏）还是过失（偶然的） 。对于舞弊（例如，故意插入未授权的代码，或不经授权修改数据） ，记住：404 条款关注的风险是至少相当可能发生的风险。本文不提供评估舞弊风险的指南，但建议使用评估企业流程中的舞弊风险的方法。换句话说，应当不仅评估舞弊发生的可能性，还要评估是否存在让其成为可能的因素（像流动资源的接近，经理制造虚假事件的动机，以及在评估控制环境时发现的其他风险） 。在这一步骤，你开始完成 GAIT 矩阵 4。然而，在你进入填写 GAIT 矩阵的步骤前（参见“评估 ITGC 过程失败的风险” ） ，理解 ITGC 过序在堆栈的每一层中如何变化是十分重要的：“应用层 IT 常
21、规控制过程” 。见下面。“数据库层 IT 常规控制过程” 。见 21 页。“操作系统层 IT 常规控制过程” 。见 21 页。“网络基础层 IT 常规控制过程” 。见 22 页。应用程序层 IT 常规控制过程下表 8 描述应用程序层的 ITGC 过程和应考虑的风险。表 4：应用软件层 IT 总控制程序和典型的风险IT 常规控制过程变更管理 变更管理包括许多潜在的风险领域，包括是否：新的或改变了的功能被适当设计和审批变更被充分测试，以确保正确运作使用者接受变化，需要时证实其功能未授权变更被阻止运作 运作具有潜在风险领域，包括：确保应用软件按照预期目标运作的控制（如，按要求的速度运行，使用当前参考
22、文档，处理所有输入文档）程序错误和异常情况的及时解决关键应用程序和数据文档的备份接触的物理安全性。 （注意：在过去，进入计算机机房里的操作控制台被认为有重大风险。现在，这种情况变得不再重要，因为更有可能通过网络破坏系统安全性，操纵数据）安全 安全包括数据风险和应用程序代码风险。IT 常规控制过程主要包括：应用程序安全、访问权的准予和撤回，以及应用程序代码的访问。注意：在实施 404 条款评估的第一年里，一个普遍的缺陷是，程序员能访问程序的源代码（尤其是网络应用程序） 。理论上，程序员能够进行未授权的变更。然而，进一步的分析和评估通常指出，这种情况导致重大错误（评估对自动控制的影响之后，等）的风
23、险较低。程序员通常没有进行未授权变更的动机（例如，他们不能接触流动资产） ，并且未发现重大错误的可能性较小。在控制测试前，GAIT 允许考虑潜在风险，这是一个更有效的方法：评估风险和仅对可能发生的风险测试，而不是先测试，再决定风险是否有可能发生。数据库层 IT 常规控制过程：一般来讲，应用层或数据库层确认的风险越低，那么在较低层风险存在的4这一讨论假设你正在使用 GAIT 矩阵。如果你使用该模块，则可以用来证明所有步骤。可能性就越小。例如，当操作层或网络基础层的变更管理缺陷理论上可能会导致自动控制功能损坏时，自动控制失败、导致重大错误的可能性相当小。下表 9 描述了数据层的 ITGC 过程：表
24、 5：数据库层计算机常规控制程序和典型风险IT 常规控制过程 内容变更管理 这一层的变更管理考虑的是非数据部分的变更风险（如数据库模式） 。经常忽视或对数据库软件发送数据到应用层的方式进行不正确的变更，会导致不完整或不正确的计算和报告。操作 该层中的操作风险识别程序和应用层操作风险识别是相同的。安全 这里提到未经授权直接获取数据。当传统的数据安全被视为 ITGC 中最关键的领域之一时，你就被鼓励运用你对整个企业流程的判断和知识，包括关键人工控制，去识别安全性风险，并关注那些至少有可能发生和导致重大错误没有被发现的风险（直接或间接通过其对关键 IT 功能的影响） 。操作系统层 IT 常规控制过程
25、操作系统层的缺陷不太可能导致重大错误（无论是直接通过对数据的未授权修改，还是间接通过其对关键 IT 功能正确发挥的影响） ，因为其影响常常立刻显现出来以使用损耗或程序处理失败的形式。然而，许多组织及其审计师对操作层的控制进行记录和测试，好像缺陷对自动控制带来不利影响的风险确实存在一样。你应当运用你的判断和对技术及关键控制（不仅是在 ITGC 过程中，而且是在整个企业流程中，包括高层次的监督控制）的广泛理解去检查这一层的风险，以确保适当的 404 条款关注点。表 10 描述了操作层的 IT 常规控制过程。表 6：操作层 IT 常规控制过程和典型风险IT 常规控制过程 内容变更管理 该层的变更管理
26、考虑的是操作系统环境的变化风险，如修护。操作 该层中的操作风险识别程序和应用层操作风险识别是相同的。安全 这里提到未经授权访问操作系统。你被鼓励运用你对整个企业流程的判断和知识，包括关键人工控制，去识别安全性风险，并关注那些至少有可能发生和导致重大错误没有被发现的风险（直接或间接通过其对关键 IT 功能的影响） 。典型的是，操作层面的风险很少延伸到基本权限之外和涉及其他特殊权限。网络基础层 IT 常规控制过程一般来讲，组织在这一层的风险很少。这一层的问题产生的影响不太直接，因此，也不太可能导致关键控制功能的失效或没有能够发现引起财务报表重大错报的数据的变更。从其他各层的风险评估所获得的信息将有
27、助于该层的风险评估。要想对这一层进行恰当的范围划定，就需要对应用程序的技术基础有一定的了解（在第二步中了解） ，并对企业流程和高层次监督程序中的关键控制强弱有一定的认识。GAIT 建议，风险的识别应尽可能关注 ITGC 程序的关键控制点。例如，如果一项高度复杂的应用程序接受并验证信用卡网上支付，那么你就应该识别出潜在的网络失败点，以限制所需测试的范围。程序 5：评估 ITGC 程序失败的风险1、对于每一个具有财务重要性的应用程序，识别具体的 ITGC 程序风险以及 IT基础中每一层的相关控制目标。简言之，经过 GAIT 矩阵的每一个单元，回答适当的问题，在下表 11 中列示。每个问题的重心都在
28、重大错误风险。就如早先讨论的，ITGC 程序风险并不直接导致财务报表中的重大错误，它们也许会导致关键自动控制的失败和其他一些关键 IT 功能（例如，关键报告）一如既往地如所要求的那样运行，进而导致不能预防和发现财务报表中的重大错误。2、记录下 GAIT 矩阵（参见 26 页的“GAIT 矩阵模板” ）或 GAIT 模板（参见 27页的“GAIT 模板” ）的结果。在必要的时候利用补充方法，如 COBIT，以保证评估的完整性。表 7： GAIT 矩阵每个单元要问的问题层级 变更管理 操作 安全应用层 是否存在至少有可能影响关键功能的变更管理 失败，以致一种或多种功能失效，以及重大错误没有被发现？
29、如果是，确认风险及相关控制目标。如果不是，与应用程序 代码 相关的变更管理控制不在范围之内。我们认为，这种情况不太可能发生的。是否存在至少有可能影响关键功能的操作 失败，以致一种或多种功能失效，以及重大错误没有被发现？如果是，确认风险及相关控制目标。如果不是，与应程序 代码 相关的操作控制不在范围之内。是否存在至少有可能影响关键功能的 安全性 失败，以致一种或多种功能失效，以及重大错误没有被发现？或者说，是否存在至少有可能导致未经授权进行某个程序中数据的变更的 安全性 失败，以致财务报表重大错误没有被发现？如果是，确认风险及相关控制目标。如果不是，与应用程序 代码 相关的安全性控制不在范围之内
30、。数据库层 是否存在至少有可能影响关键功能的变更管理 失败，以是否存在至少有可能影响关键功能的操作 失败，以致一是否存在至少有可能影响关键功能的 安全性 失败，以致一种或多种功致一种或多种功能失效，以及重大错误没有被发现？如果是，确认风险及相关控制目标。如果不是，与应用程序 数据库 相关的变更管理控制不在范围之内。种或多种功能失效，以及重大错误没有被发现？如果是，确认风险及相关控制目标。如果不是，与应用程序 数据库 相关的操作控制不在范围之内。能失效，以及重大错误没有被发现？或者说，是否存在至少有可能导致未经授权进行数据和其他部分（如数据库模式）的变更的安全性 失败，以致财务报表重大错误没有被
31、发现？如果是，确认风险及相关控制目标。如果不是，与应用程序 数据库 相关的安全性控制不在范围之内。操作系统层是否存在至少有可能影响关键功能的变更管理 失败，以致一种或多种功能失效，以及重大错误没有被发现？如果是，确认风险及相关控制目标。如果不是，与应用程序 操作系统相关的变更管理控制不在范围之内。是否存在至少有可能影响关键功能的操作 失败，以致一种或多种功能失效，以及重大错误没有被发现？如果是，确认风险及相关控制目标。如果不是，与应用程序 操作系统 相关的操作控制不在范围之内。是否存在至少有可能影响关键功能的 安全性 失败，以致一种或多种功能失效，以及重大错误没有被发现？如果是，确认风险及相关
32、控制目标。如果不是，与应用程序 操作系统 相关的安全性控制不在范围之内。网络基础层是否存在至少有可能影响关键功能的变更管理 失败，以致一种或多种功能失效，以及重大错误没有被发现？如果是，确认风险及相关控制目标。如果不是，与应用程序 网络基础相关的变更管理控制不在范围之内。是否存在至少有可能影响关键功能的操作 失败，以致一种或多种功能失效，以及重大错误没有被发现？如果是，确认风险及相关控制目标。如果不是，与应用程序 网络基础 相关的操作控制不在范围之内。是否存在至少有可能影响关键功能的 安全性 失败，以致一种或多种功能失效，以及重大错误没有被发现？如果是，确认风险及相关控制目标。如果不是，与应用
33、程序 网络基础 相关的安全性控制不在范围之内。步骤 4 识别满足控制目标的关键 ITGC 所有风险和相关 IT 控制目标确定之后，就能够确定 ITGC 中的具体关键控制点。框架结构，例如 COBIT，有很大的帮助。这种 GAIT 方法论并不延伸到404 条款测试的下一步。我们唯一能够提供的建议就是，每一个 ITGC 关键控制点都应该与通过 GAIT 确定的 IT 控制目标相联系，从而与有风险的关键 IT 功能的适当操作相联系。这一部分提供的信息是关于：“评估 ITGC 的存在性” 。见下文。“选择可以信赖的关键控制，并测试” 。见 30 页。评估 ITGC 的存在性ITGC 常常被认为很普遍，
34、因为 ITGC 过程中的控制倾向于影响不止一项自动控制，并且很多控制影响不止一个应用程序。到了这一步，方法是：识别，对于大多数组织，相同风险，当对多个应用程序进行风险评估时。例如，不同的应用程序可能会使用相同的操作系统或数据库。不用识别合计风险，当在多个具有财务重要性的应用程序中的关键 IT 功能风险受到单个 ITGC 程序失败的影响时。那就是说，关键功能的潜在失败可能会累积成很可能发生重大错误的风险。单个 ITGC 程序控制的缺陷会影响不同具有财务重要性的应用程序中的关键 IT 功能或复杂数据库。尽管单独一个缺陷不会有高风险，但 ITGC 程序缺陷的累积影响会产生高风险。GAIT 利用之前阶
35、段的结果去引导你进行独立评估。这个独立评估测试单个ITGC 程序或风险是否会影响多个应用程序，以及是否很有可能导致多个关键控制失败，这些失败合计起来至少有可能产生重大错误。在这些情况下，要把风险加到那些需要识别的 ITGC 程序关键控制中。程序 6：评估 ITGC 的存在性考虑以下列在表 12 中的问题。表 8：评估存在性每个问题 评价下面的有关于：应用层，是否存在至少有可能影响多个应用程序及其关键 IT 功能的变更管理风险、操作风险或安全风险？数据库，是否存在至少有可能影响多个应用程序及其关键 IT 功能的变更管理风险、操作风险或安全风险？操作系统，是否存在至少有可能影响多个应用程序及其关键
36、 IT 功能的变更管理风险、操作风险或安全风险？网络基础，是否存在至少有可能影响多个应用程序及其关键 IT 功能的变更管理风险、操作风险或安全风险？如果答案是“否” ，则 IT程序不在应用层的范围之内。记录其原理。如果答案是“是” ，确认风险。提出这些风险的IT 控制目标由人们普遍认可的 IT 审计实践定义（参见“原则 4”） 。记录评估和相应 IT 目标的原理。整个 IT 环境，是否存在影响各层多个应用程序的风险？例如，同一安全暴露是否至少有可能会导致应用程序代码和数据出现未经授权的数据，以致重大错误很有可能没有被发现？选择可以信赖的关键控制并测试GAIT 提供了一种识别风险和相关 ITGC
37、 控制目标的方法，ITGC 过程中的关键控制应当包括在 404 条款测试的范围之内。但是，不考虑以下问题的关键ITGC 适不完整的。程序 7：选择可以信赖的关键控制并测试提出下表 13 的问题：表 9：识别关键 ITGC问题 内容信赖人工控制 广泛审视一下所有控制，以决定选择哪些具有预防性和发现性的控制组合可以信赖。很多组织有很强的监督机制和其他控制，可能在财务报表出具前发现重大错误。当确定哪些控制作为关键并加以信赖时，要决定是否包含更多的具体控制（如关键控制）作为预防措施，或是否要依赖更高层次的控制。周期的有效性控制（如确认存货中的实物存货或其他资产）可以发现导致重大错误的自动控制缺陷。基准
38、 基准限制了关键自动控制和其他关键 IT 功能（例如，关键报告）的测试。基准应用在：一般是应用层变更管理控制较强的地方。它使那些控制联合起 来具有可靠性，用自动控制的前期测试取代每年对每一个关键自动控制的测试。在应用程序跟前一年相比没有发生变化的地方，当所有自动控制都被成功测试时。例如，如果检查 SAP 的审计线索并且证实没有发生变化，那就没有必要去测试自动控制，应用层也就没有 ITGC 变更管理风险了。自动控制的延伸测试尽管一年中的 ITGC 有效可以限制自动控制测试的样本为1，但如果在一个应用程序中只有几个自动控制，不信赖ITGC 也许会更加有效。少数自动控制可以进行更频繁的测试，例如每季
39、末，以确保其有效运行，而不用依靠 ITGC 控制。如果你采用这个方法，请使用基于控制操作频率的抽样方法测试关键自动控制。例如，如果每月使用关键报告，那么用于测试报告完整性和准确性的样本规模就应该以此控制操作频率为基础。只有在用 GAIT 进行了全面评估之后才能考虑使用此方法，用来理解应用程序的所有风险。例如，延伸测试也许不能发现数据库层、操作系统层或网络基础层的风险。步骤 5 由 “合适人员 ”进行检验一个严格的 ITGC 程序风险的评估也许会导致与以前的评估相比起来识别出的风险较少，所需要的关键 ITGC 相对较少。这也许是因为其他的风险并不被认为至少有可能导致能引起重大错误的关键功能失效。这并不意味着 IT 没有控制；这只是表明那些风险也许不在 404 条款测试的范围之内，基于风险的视角。程序 8：检查风险1、证实风险和关键控制意味着对财务报表存在风险，以一个独立、严谨的官员的眼光来看。2、保证风险的选择是合理的，前提是组织风险的容忍度在 404 条款范围之内。所应用的方法是保守的还是激进的？
