Cobit审计指南+

信息技术审计指南

2002年10月

1.2 IT长期计划

计划和组织

控制的IT过程：

定义战略性的IT规划 满足的业务需求：

既要谋求信息技术机遇和IT业务需求的最佳平衡，又要确保其进一步地完成 实现路线：

在定期从事的战略规划编制过程中，要逐渐形成长期的计划，长期的计划应定期地转化成设置清晰并具体到短期目的的操作计划

需要考虑的事项： 企业的业务发展战略

IT如何支持业务目标的明确定义

技术解决方案和当前基础设施的详细清单 追踪技术市场

适时的可行性研究和现实性检查 已有系统的评估

在风险、进入市场的时机、质量方面，企业所处的位置 需要高级管理层出钱、支持和必不可少的检查 信息规范 IT资源 P 效果 * 人员 S 效率 * 应用 保密 * 技术 完整 * 设施 可用 * 数据 遵从 可靠

1.1 作为机构长期和短期计划一部分的IT

1 定义战略性的信息技术规划（PO1）

高级管理层对开发和实施履行机构任务和目标的长期和短期的计划负责。在这一方面，高级管理层应确保IT有关事项以及机遇被适当地评估，并将结果反映到机构的长期和短期计划之中。IT的长期、短期计划应被开发，确保IT的运用同机构的使命与业务发展战略相结合。

IT管理层和业务过程的所有者要对有规律地开发支持机构总体使命和目的实现的IT长期计划负责。计划编制的方法应包括寻求来自受IT战略计划影响的相关内外部利害关系人引入的机制。相应地，管理层应执行一个长期计划的编制过程，采用一种结构化的方法，并建立一个标准的计划结构。

获得了解：

访谈：

首席执行官（CEO） 首席运营官（COO）

1.6 IT计划的交流

1.8 现有系统的评估

1.4 IT长期计划的变更

1.7 IT计划的监控和评估

1.5 IT功能的短期计划编制

1.3 IT长期计划编制——方法与结构

管理层应确保IT长期和短期计划同业务过程所有者以及跨越机构的其他相关部门人员的充分沟通。

管理层应建立一个流程，获取和报告来自业务过程所有者和用户有关长期和短期计划的质量及有效性的反馈。获取的反馈应予以评估，并在将来的IT计划编制中加以考虑。

IT管理层和业务过程的所有者应确保IT长期计划有规律地转换成IT短期计划。这样的短期计划应确保适当的IT功能资源以与IT长期计划内容相一致的基础上来分配。短期计划应定期地进行再评估，并被作为适应正在变化的业务和IT环境所必须的事项而改进。可行性研究的及时执行应确保短期计划的实行是被充分地启动的。

在开发或变更战略规划或长期计划、IT计划之前，IT管理层应按照业务自动化的程度、功能性、稳定性、复杂性、成本、优势和劣势，评估现有信息系统，以确定现有系统支持机构业务需求的程度。

IT管理层和业务过程所有者应确保及时、准确地修改IT长期计划的过程的到位，以适应机构长期计划的变化和IT环境的变化。管理层应建立一个IT长期和短期计划开发和维护所需要的。

对于长期计划的编制过程来讲，IT管理层和业务过程的所有者应建立并采用一种结构化的方法。这样可以制定出高质量的计划，含盖什么、谁、怎样、什么时间和为什么等基本的问题。IT计划的编制过程应考虑风险评估的结果，包括业务、环境、技术和人力资源的风险。计划编制期间，需要考虑和充分投入的方面包括：机构的模式及其变化、地理的分布、技术的发展、成本、法律法规的要求、第三方或市场的要求、规划远景、业务过程再造、员工的安置、自行开发或者外包、数据、应用系统和技术体系结构。已做出选择的好处应被明确地确定下来。IT长期和短期计划应使绩效指标和目标合并在一起。计划本身还应参考其它的计划，比如机构的质量计划和信息风险管理计划。

对高级和详细的控制目标进行审计：

评估控制：

首席财务官（CFO） 首席信息官（CIO） IT计划/指导委员会成员

IT高级管理层和人力服务职员 获得：

与计划编制过程想关联的和程序 高级管理层的指导角色和责任 机构的目标和长短期的计划 IT的目标和长短期的计划

状况的报告和计划/指导委员会的会议纪要

评定遵从性：

测试：

来自反映计划编制过程的IT计划编制/指导委员会的会议纪要 计划编制方法的可交付使用物的存在，作为预先的规定

相关IT的初始被包括在IT长短期的计划当中（也就是硬件的变化、容量计划编制、信息体系结构、新系统开发或获取、灾难恢复计划编制、新处理平台的安装，等等）

IT初始支持长短期计划，并要考虑调查、培训、人员安置、设施、硬件和软件的需求 IT初始的技术含义已经被确定

最优化当前和将来IT投资的考虑已经给出

IT长短期计划与机构的长短期计划和组织的需求保持一致 计划已经发生改变，以反映正在变化的条件 IT长期计划定期转化成短期计划

考虑是否：

IT或者业务的企业和程序选择了一种结构化的计划编制方法 方法到位，以便明确地表达并能够修改计划，起码它们要包括： • 机构的使命和目的

• 支持机构使命和目的的IT初始 • IT初始的机遇

• IT初始的可行性的研究 • IT初始的风险评估

• 当前和未来IT的最佳投资

• 反映企业使命和目的变化的IT初始的再造 • 数据应用、技术和机构可选择战略的评估

机构的变化、技术的发展、规章的要求、业务过程的再造、员工的安置、自己开发和外包，等等被考虑，并在计划编制过程中充分地从事

长短期的IT计划存在，是当前的，充分针对全部企业、它的使命和关键的业务职能部门 IT项目由IT计划编制方法中确定的适当文档所支持

确保IT目标和长短期计划持续地满足机构目标和长短期计划的检查点存在 由过程所有者和高级管理层评价和结束的IT计划发生

根据业务自动化程度、功能性、稳定性、复杂性、成本、优势和弱点，IT计划评估现有的信息系统 对信息系统及其支持的基础设施的长期计划编制的缺乏，导致系统不能支持企业的目标和业务的过程，或者不能提供适当的完整、安全和控制

存在实现计划的任务

2.1 信息体系结构模型

证实没有满足业务目标的风险：

2 定义信息体系结构（PO2）

控制的IT过程： 定义信息体系结构 满足的业务需求： 优化信息系统的机构 实现路线：

创建并维护一个业务信息模型，确保定义适当的系统，以优化信息的使用 需要考虑的事项：

自动化的数据存贮和字典 数据语法规则

数据所有权和关键性/安全性程度分类 表述业务的信息模型

企业信息体系结构标准信息 信息规范 IT资源 P 效果 人员 S 效率 * 应用 S 保密 技术 S 完整 设施 可用 * 数据 遵从 可靠

信息应与需求保持一致，并应以某种格式和期限进行识别、获取和交流，而这些格式和期限能使人们及时、有效地履行他们的职责。相应地，围绕企业的数据模型和相关的信息系统，IT的职能应是建立并有规律地更新信息体系结构模型。信息体系结构模型应与IT长期计划保持一致。

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的战略IT计划的基准 确保IT初始反映机构的使命和目的的IT计划的详细评价

决定是否机构之内已经知道的虚弱区域正在被确认为计划当中IT解决方案的一部分而加以改进的IT计划的详细评价

确定：

满足机构使命和目的的IT失败

与长期计划相匹配的短期计划的IT失败 满足短期计划的IT项目的失败 满足成本和时间准则的IT失败 错过的业务机遇 错过的IT机遇

评估控制：

获得了解：

2.4 安全等级

2.3 数据分类方案

2.2 企业数据字典和数据语法规则

对于上述确定的每一个“不需要保护”级别以上的数据分类，管理层应定义、执行和维护这些安全等级。对于每一个分类来讲，这些安全等级应描述适当的（最小的）一套安全和控制尺度，应定期进行再评估并做相应的修改。对于区域范围广阔的企业，应建立支持不同安全等级的标准，以适应正在发展的电子商务、移动计算和远程办公环境的需要。

访谈：

首席信息官（CIO） IT计划/指导委员会成员 IT高级管理层 安全官 获得：

与信息体系结构相关的和程序 信息体系结构模型

支持信息体系结构模型的文档，包括企业数据模型 企业数据字典 数据所有者

高级管理层指导的角色和责任 IT的目标和长短期计划

状况报告和计划编制/指导委员会会议纪要

IT的职能应确保包含机构数据语法规则的企业数据字典的建立以及持续的更新。

对高级和详细的控制目标进行审计：

考虑是否：

IT和程序选择了数据字典的开发和维护

用于修改信息体系结构模型的过程是以长短期计划为基础的，考虑了相关成本和风险，并且该模型变化之前，要确保高级管理层同意

有一个过程用来保持数据字典和数据语法规则处于最新状态

有一个媒介用来分发数据字典，确保开发区域的可达性并立即反映变化

IT和过程要选择数据的分类，包括安全种类和数据所有者，数据分类的访问规则要被清晰和适当

在按信息类别（如安全类）进行分类的数据放置以及所有权分配方面，应建立一个总体的分类框架，应适当定义各类别的访问规则。

评定遵从性：

3 决定技术方向（PO3）

证实没有满足业务目标的风险：

测试：

信息体系结构模型上的变化，确定这些变化反映了IT长短期计划及其所确定的成本和风险 评估数据字典的任何修改以及数据字典上变化的影响，确保它们被有效地沟通 各种运作的应用系统和开发项目，以确定数据字典被用作数据定义

足够的数据字典文档，以确定这些文档为每一个数据项定义了数据的属性和安全等级 数据分类、安全等级、访问等级和缺省的适当性 每一个数据分类都要清晰地定义： • 谁可以访问

• 谁对决定适当的访问级别负责 • 所需访问的明确批准

• 访问的特定需求（也就是非披露或者保密性协议）

地定义

要为那些不包含数据分类标识符的数据资产定义缺省的分类标准 IT和程序要选择以下内容：

• 需要数据所有者（在数据所有者上定义）的授权过程要到位，以便批准该数据的所有访问以及数据的安全属性

• 每一个数据分类的安全等级要被定义

• 访问等级被定义，并且对于数据分类来说是适当的

• 访问敏感数据需要清楚的访问级别，数据的提供要以“需要知道”为基础

执行：

依照类似机构或适者国际标准/公认的行业最好实践的信息体系结构模型的基准 针对关键元素的完整性，数据字典的详细评价

对定义为敏感数据的安全等级的详细评价，以校验访问的适当授权被获得，被许可的访问与定义在IT和程序中的一致

确定：

信息体系结构模型和企业数据模型、企业数据字典、相关信息系统以及IT长短期计划中的矛盾 过时的企业数据字典项和由于数据字典变化的不良的沟通丧失了时效性的数据语法规则？？？ 所有者不清楚和/或没有适当定义的数据项 没有被适当定义的数据分类

与“需要才能知道”的原则不一致的数据安全等级

控制的IT过程： 决定技术方向 满足的业务需求：

利用目前可用的和正在出现的技术，推动业务战略的实施并使业务战略成为可能 实现路线：

建立并维护技术基础设施计划，该计划，依据产品、服务和交付机制，建立并管理技术能够提供的清

晰和现实的预期

需要考虑的事项： 当前基础设施的容量

通过可靠的来源，监测技术发展 引导概念的检验 风险、约束和机遇 获取的计划

移植战略和路线 与供应商的关系 的技术再评估

硬件和软件的性能/价格比的变化 信息规范 IT资源 P 效果 人员 S 效率 应用 保密 * 技术 完整 * 设施 可用 数据 遵从 可靠

3.5 技术标准

3.4 硬件和软件获取计划

3.1 技术基础设施计划编制

3.2 监测未来的趋势和法规

3.3 技术基础设施的不确定事件

IT的职能部门应建立并有规律地更新与IT长期和短期计划保持一致的技术基础设施计划。这样的计划应围绕诸如系统体系结构、技术方向和移植策略等方面。

技术基础设施计划应在偶然事件方面（即基础设施的冗余、恢复、充足性和发展能力）进行系统地评估。

IT的职能部门应能够确保对未来趋势和法规环境的持续监测，以便这些因素能够在技术基础设施计划的开发和维护期间被考虑在内。

以技术基础设施计划为基础，IT管理层应定义技术规范以培养标准化的意识。

IT管理层应确保制定硬件和软件的获取计划，并要反映在所确定的技术基础设施计划的需求中。

评估控制：

获得了解：

评定遵从性：

访谈：

首席执行官（CEO） 首席运营官（COO） 首席财务官（CFO） 首席信息官（CIO） IT计划/指导委员会成员 IT高级管理层 获得：

与技术基础设施计划编制和监控相联系的和程序 高级管理层指导角色和责任 机构目标和长短期计划 IT目标和长短期计划 IT硬件和软件获取计划 技术基础设施计划 技术标准

状况报告和计划编制/指导委员会会议纪要

对高级和详细的控制目标进行审计：

测试：

IT管理层理解并使用技术基础设施计划

技术基础设施计划上的变化，以确定相关的成本和风险，这些变化要反映在IT长短期计划的变化中 IT管理层要理解监控和评估正在出现技术的过程，并要将适当的技术合并到当前的IT基础设施之中 IT管理层要理解系统评估技术计划意外的过程（也就是说，基础设施的冗余、恢复力、充足性和发展能力）

考虑是否：

为确认被提议的变化首先被检查以评估相关联的成本和风险，为确认高级管理层的批准先于计划的变化被获得，有一个创造并有规律地更新的技术基础设施计划的过程

技术基础设施计划与IT长短期计划相比较

有一个过程来评估机构的当前技术状态，确保环绕诸如系统体系结构、技术方向和移植战略等方面 IT和程序确保选择了评估和监控当前和将来的技术趋势和规章条件的要求，并且在技术基础设施计划的开发和维护期间被考虑

技术获取的后勤和环境影响要被计划

IT和程序确保选择了系统地评估技术计划意外的需求（也就是基础设施的冗余、恢复力、足够性和发展能力）

IT管理层评估正在出现的技术，并将适当的技术合并到当前的IT基础设施之中 对于硬件和软件的获取计划来讲，它是遵从技术基础设施计划中所确定的要求并被适当地批准的实践 在技术基础设施计划中所描述的技术组成的技术标准是到位的

证实没有满足业务目标的风险：

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的技术基础设施计划编制的基准 针对关键元素的完整性，数据字典的详细评价 为敏感数据而定义的安全等级的详细评价 确定：

信息系统和IT长短期计划相关的信息体系结构模型和企业数据模型、企业数据字典的矛盾 企业数据字典条款和数据语法规则的过时 没有在技术基础设施计划中选择的以外方面

没能反映技术基础设施计划需求的IT硬件和软件的获取计划

与技术标准不一致的技术基础设施计划或IT硬件和软件获取计划 数据字典中丢失的关键元素

没有按照同样标准分类或者没有安全等级的敏感数据

4 定义信息技术的机构及关系（PO4）

为了充分地适应目前的已安装的硬件/软件以及在当前被批准的增加的新的硬件/软件，IT职能部门现有的物理环境

硬件和软件获取计划遵从IT长短期计划，并要反映技术基础设施计划中所确认的需求 技术基础设施计划选择利用当前和将来的技术

技术标准被遵循，并作为开发过程的一部分而被合成一体

被允许的访问与IT和程序中所定义的安全等级相一致，到位的访问要经过适当的授权

控制的IT过程： 定义IT的机构及关系 满足的业务需求： 提供正确的IT服务 实现路线：

定义一个数量上相配、具有角色和职责所要求技能的机构，与业务部门沟通、联合在一起，促进战略的实现，并规定有效的方向和适当的控制

需要考虑的事项： 董事会层面上的IT职责

管理层对于IT的指导和监督 IT与业务的结合

关键决策过程中IT的参与 机构的灵活性 清晰的角色和职责 平衡授权与监督 工作岗位的描述

人员级别和关键的人员

在安全、质量和内部控制功能方面的机构配置 职责的分离 信息规范 IT资源 P 效果 * 人员 S 效率 应用

保密 完整 可用 遵从 可靠

4.4 角色和责任

4.5质量保证的责任

4.7 所有者和管理者

4.3 机构绩效的评价

4.2 IT职能的机构设置

4.1 IT计划或指导委员会

技术 设施 数据

4.6 逻辑和物理安全的责任

应设置一个框架来评价机构的机构，以不断地满足目标和变化的环境。

机构的高级管理层应指定一个计划或者指导委员会，来检查IT的职能及其活动。委员会的会员应包括来自高级管理层、用户管理层和IT职能方面的代表。委员会应实行例会制度，并向高级管理层报告。

管理层应为信息安全经理正式地分配确保机构信息资产物理和逻辑安全的责任，并负责向高级管理层报告。最起码，安全管理职责应建立在整个机构范围的层次上，以便能够处理一个机构内的全部安全问题。如果需要，系统细节层次上的附加安全管理责任也应被分配，以应对相关的安全问题。

管理层应确保机构中所有人员都具有并理解他们在相关信息系统中的角色和责任。所有的人员应具有足够的权力来行使分派给他们的角色和责任。角色的设置应考虑适当的职责分离。没有那个人能够控制一个交易或事件的所有关键环节。每个人都应认识到他们在内部控制和安全方面具有一定的责任。因此，应机构并承担起有规律的一些活动，以增强这方面的意识和纪律。

管理层应为IT职能部门的成员分配质量保证职能履行的责任，并确保适当的质量保证、系统、控制和存在于IT职能质量保证小组中的专家们的交流。IT职能内机构的布置以及质量保证小组的职责和规模应满足机构的需求。

在整个机构机构设置IT职能过程中，高级管理层应确保其权力、关键时刻以及与用户部门的性到必要的程度，以便在执行时能够保证有效的IT解决方案和充分的进展，并要建立与顶级管理层的伙伴关系，以便在确定和解决IT问题时，能够帮助他们增强意识、理解和技能。

管理层应正式建立一个指定数据所有者和管理者的结构。他们的角色和责任应清楚地定义。

4.9 监督

4.10 职责分离

4.11 IT人员配备

4.13 关键的IT人员

4.8 数据和系统的所有者

IT管理层应详细说明和识别关键的IT人员。

4.14 与员工签约的和程序

4.12 IT员工工作和职位的描述

管理层应确保所有信息资产（数据和系统）都已指定了所有者，他们对信息资产的分类和访问权限具有决策的权利。典型地，系统所有者可以将日常管理委派给系统的交付/操作小组，将安全职责委派给安全管理员。然而，所有者仍然要保留对适当安全尺度维护的责任。

为了IT职能部门控制咨询和其它签约个人的活动，确保机构的信息资产处于保护之中，管理层应详细说明和执行相关的和程序。

管理层应确保建立IT员工的职位描述，并有规律地被更新。这些职位描述应清楚地描绘权力和责任两方面，包括相关职位要求的技能和经验的详细说明，并要适合在绩效评估中使用。

员工需求评估应有规律地执行，以保证履行IT职能所需足够数量能胜任的IT员工。员工需求应至少每年评估一次，或根据业务、运作及IT环境的主要变化而执行。评估结果应尽快执行，以确保现在和将来员工的充足。

高级管理层应实施角色和职责的分离，避免单独的个人扰乱某个关键的过程。管理层还应确定每个人仅执行其工作和职位规定的各自的职责。尤其是下列职责之间责任分离的应维护。

信息系统使用 数据录入 计算机操作 网络管理 系统管理

系统开发和维护 变更管理 安全管理 安全审计

高级管理层应执行适当的IT职能的监督实践，以保证角色和责任被完全地行使，评估所有的个人是否有足够的权力和资源完成他们的角色和职责，并要全面地评价关键的绩效指标。

盟

4.15 关系

评估控制：

获得了解：

访谈：

首席执行官（CEO） 首席运营官（COO） 首席财务官（CFO） 首席信息官（CIO） 质量保证官 安全官

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投资

证实没有满足业务目标的风险：

5 管理信息技术投资（PO5）

所有的数据和系统具有一个所有者或者管理人，他们负责控制数据和系统的水平 所有数据和系统资产的访问由资产的所有者审批

与职位（工作）相联系的权利和监督的直线要与在职者的义务相称 职位（工作）描述清楚地描绘权利和责任两者

职位（工作）描述清楚地描述所需的业务、相关的和技术的资格 职位（工作）已经被精确地沟通，并由个人所理解

IT职能部门的职位（工作）描述包含已经沟通给个人的关键绩效指标

IT职员的义务和责任要对应于已经公布的职位（工作）描述和机构的机构图两者

关键职位的职位（工作）描述到位，包括机构关于信息系统、内部控制和安全的训令 职位（工作）描述的精确性要与这些职位在职者的当前责任相比较 遵从IT职能部门内有意的职责分离以及职责的种类和范围 IT人员安置的维持能力

作为责任、权利和绩效标准的适当性和透明度的基础，职位（工作）描述的适当性 合同管理的责任分配给了适当的人员

合同的术语与正常的机构合同的标准相一致，标准契约术语和条件已经由法律的律师评价和评估，它们的同意意见要获得

合同包含适当的有关遵从性的条款：法人的安全和内部控制、信息技术标准 过程和/或结构规定成功关系所必须的有效果和有效率的协调

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的机构和关系的基准 决定由无效的IT计划/指导委员会所引起的机构方面影响的详细评价

在处理信息系统问题和执行技术解决方案方面，测量IT职能部门进步的详细评价

评估机构的机构、人员和个人能力、分配的角色和责任、数据和系统所有权、监督、职责分离等的详细评价

决定在满足机构需求的有效性方面的质量保证职能部门的详细评价

决定在提供机构范围内信息安全（逻辑和物理两者）和信息安全意识培训有效性方面的安全职能的详细评价

确定这些合同已经由交易双方适当地执行并且遵从机构的标准合同术语的合同实例的详细评价 确定：

由于IT计划/指导委员会无效监督所引起的IT职能及其活动的弱点 导致IT职能无效果或无效率的机构机构的缝隙、重叠，等等

不适当的机构机构、缺少的职能、不充足的人员、能力不足、不适当的角色和责任、数据和系统所有权的混乱、监督的问题、缺乏职责分离，等等

确实满足质量保证要求的正在开发、修改或者执行的系统

确实满足安全（或者是逻辑的，或者是物理的，或者是两者兼顾）需求的正在开发、修改或者执行的系统

不能满足机构的合同要求的合同

IT职能部门和各种各样其它有兴趣的IT职能部门的内外之间的无效协调和沟通

5.1 年度IT运营预算

5.2 成本和收益的监控

5.3 成本和收益的合理性

满足的业务需求：

保证资金并控制财务资源的支出 实现路线：

由业务决定的定期投资和运作预算的建立和审批 需要考虑的事项： 资金的选择

清晰的预算所有者 实际支出的控制

成本的合理性和所有者总成本的意识 收益的合理性和收益实现的责任制 技术和应用软件的生命周期 要与企业的业务战略相结合 效果的评估 资产管理 信息规范 IT资源 P 效果 * 人员 P 效率 * 应用 保密 * 技术 完整 * 设施 可用 数据 遵从 S 可靠

管理控制应设置到位，以保证IT职能部门交付服务的成本是合理的并符合行业标准。由IT活动衍生出来的收益也应做同样应的分析。

管理层应建立成本监测的过程，将实际支出与预算进行比较。此外，由IT活动衍生出来的可能存在的收益应被确定和报告。对于费用监测来讲，实际数据的来源应以机构的会计系统为基础，该系统应例行公事地纪录、处理并报告与IT职能部门的活动相关的成本。对于收益的监测来讲，高层次的绩效指标应被详细地说明，有规率地进行报告并对其适当性进行评价。

高级管理层应执行预算编制过程，按照机构的长期和短期计划以及IT的长期和短期计划，保证年度IT运作预算的建立和批准。应调查资金的选择。

价

执行：

评估控制：

获得了解：

评定遵从性：

用来监控成本的工具是有效的并适当地使用

证实没有满足业务目标的风险：

访谈：

首席财务官（CFO） 首席信息官（CIO） IT计划/指导委员会成员 IT高级管理层 获得：

与预算和成本核算相联系的机构的、方法和程序 与预算和成本核算相联系的IT和程序

当前和最近的以前年度IT职能部门的年度运作预算 机构目标和长短期计划 IT目标和长短期计划

高级管理层计划/指导的角色和责任

与差异监控和控制相连接的差异报告及其它沟通 状况报告和计划/指导委员会会议纪要

对高级和详细的控制目标进行审计：

考虑是否：

IT预算的过程与机构的过程一致

确保与机构的预算、机构的长短期计划、IT长短期计划相一致的年度IT运作预算的准备和适当审批的和程序的到位

预算过程要与在准备阶段起作用的IT职能部门的主要单位的管理层分享

有规律地监控实际成本，并将其与计划的成本相比较的和程序要到位，实际的成本是以机构的成本会计系统为基础的

保证IT职能部门的服务交付具有合理的成本并遵守行业成本的和程序到位

测试：

在证明IT年度运作计划是合理的方面，IT预算的支持是适当的 IT支出的种类是全面的、适当的并进行了适当的分类

日常记录、处理和报告与IT职能部门活动相联系的成本的系统是适当的 成本监控过程充分地比较实际的预算

由受影响的用户组的管理层、IT职能部门以及机构的高级管理层所进行的成本/效益分析被充分地评

6.1 积极的信息控制环境

6.2 管理层在方面的责任

依照类似的机构或者适当的国际标准/公认的行业最好实践的预算和成本的基准

最近的过去和当前的年度预算，及与之相对的结果、差异和所采取的校正行动的详细评价 确定：

没有按照机构的预算和长短期计划、IT长短期计划懂得IT预算 没有被捕捉到的IT职能部门的实际成本

6 沟通管理的目标和方向（PO6）

控制的IT过程：

沟通管理的目标和方向 满足的业务需求：

确保用户知晓并理解这些目标 实现路线：

建立并与用户团体进行交流；此外，需要建立标准，以便将战略性选择转化为实际及便于使用的用户规则

需要考虑的事项： 清晰统一的使命

连接业务目标的技术方针 行为/道德规范的法规 质量承诺

安全和内部控制 安全和内部控制实践 实例引导

持续的沟通程序

提供指导和遵从性检查 信息规范 IT资源 P 效果 * 人员 效率 应用 保密 技术 完整 设施 可用 数据 S 遵从 可靠

对于覆盖总体目标和方针的而言，管理层应对的阐明、开发、声明、公布和控制承担全部责任。适当性的评价应有规率地进行。撰写的及其程序的复杂性应总是与机构的规模和管理风格相一致。

为了给正确的行为提供指导，消除不道德行为的诱惑并严肃纪律，管理层应建立一个全机构范围内培育积极控制环境的框架和认知程序。这些框架和程序应专注于员工的诚信、伦理价值和能力以及管理哲学、操作风格和义务。针对IT的各方面，包括安全和业务持续性计划，要给予具体的考虑。

6.9 知识产权

6.7 质量义务

6.5 的维护

6.4 执行资源

6.10 特定问题

6.3 机构的沟通

6.6 遵从、程序和标准

6.8 安全和内部控制框架

管理层应定义、形成文件并维护与企业价值观和相一致的质量价值观、和目标，这些质量价值观、和目标应被IT职能部门的所有层次所理解、执行和维持。

为了的执行，为了确保的遵循，管理层应对适当的资源做出计划，以使它们构筑到并成为运作的一个完整组成部分。管理层还应监控执行的及时性。

管理层应确保合适的程序设置到位，以判定每个人是否理解了执行的和程序，以及这些程序和是否被遵循。伦理道德、安全和内部控制标准的遵从程序应由最高管理层来建立，并由实例来促进其贯彻执行。

应被有规率地调整，以适应变化的条件。起码应按年或者根据运行或业务环境的重大变化而进行重新评估，评估它们的充分性和适当性，并做必要的修改。对于定期的评价以及标准、、方针和程序的审批，管理层应提供一个框架和过程。

管理层应确保机构在机构内的所有层次上被清晰地沟通、理解并被接受。沟通过程应由一套使用灵活多变沟通手段的有效计划所支持。

管理层应规定并执行有关自行开发和签约开发软件的知识产权方面的书面。

措施应设置到位，确保细节问题的建立，以便在从事特殊的活动、应用、系统或技术时，归档管理决策。

管理层应对开发并维护框架的付全部责任，这个框架设立机构的总体安全和内部控制的方法，以建立并改善IT资源的保护和IT系统的完整。应服从总体业务目标，目标是：通过预防性措施、及时辨识不规范行为、损失和及时恢复，使风险最小化。这种措施应以成本/收益分析为基础，并应区分优先顺序。另外，管理层应确保这些高层次的安全和内部控制详细说明了目的和目标、管理结构、机构内的适用范围、在所有层次上执行的责任的定义和分配以及对违背安全和内部控制行为的处罚的定义。应详细说明框架定期再评估的标准，以对正在变化着的机构、环境和技术需求做出支持响应。

评估控制：

获得了解：

6.11 IT安全意识的沟通

对高级和详细的控制目标进行审计：

访谈：

首席执行官（CEO） 首席运营官（COO） 首席财务官（CFO） 首席信息官（CIO） 安全官

IT高级管理层

IT计划/指导委员会成员 获得：

与管理层的积极控制框架、认知程序、安全和内部控制框架、IT质量程序相关的和程序 高级管理层的指导角色和责任 机构的目标和长短期计划 IT的目标和长短期计划

状况报告和计划/指导委员会会议纪要 沟通程序

考虑是否：

机构的和程序创造了一个框架和程序，给予信息技术以特别的关注，培育一个积极的控制环境，并选择如下的方面：

• 完整 • 伦理价值 • 行为规范

• 安全和内部控制 • 人员的能力

• 管理哲学和运作风格

• 由董事会的董事或相同人物提供的问责制、注意和方向 由例子说明顶级管理层促进积极的控制环境

管理层已经接受了明确叙述、开发、归档、发布、控制并有规律地评价治理总目标和方向的的责任

提供相关于管理层的积极的控制环境的正在进行的沟通和培训的正式的认知程序存在

确保适当的和足够的资源被分配，以便以及时的方式执行机构的的机构和程序存在 确保个人理解被执行的和程序，和程序被追随的适当的程序到位

IT和程序定义、归档并维持一个正式的治理系统和服务质量的哲学和目标，其产生要与机构

应通过一个IT安全意识教程，将IT安全沟通给每一个IT用户，并保证对IT安全重要性的完整理解。这个教程应传达这样一种信息，那就是IT安全将使它的机构、它的所有雇员受益，每个人对此都负有责任。IT安全意识教程应代表管理层的观点并被他们所支持。

评定遵从性：

证实没有满足业务目标的风险：

的哲学、和目标相一致

IT管理层确保质量哲学、和目标被理解、执行并在IT职能部门的所有层次上执行

选择了定期评价和重新批准的关键标准、方向、相关于信息技术的和程序需求的程序存在 高级管理层已经接受了为总体的安全和内部控制方法开发一个框架的全部责任

安全和内部控制框架归档了详细的安全和内部控制、目的和目标、管理结构机构之内的范围、责任的分配以及遵从安全与内部控制失败相关的处罚和惩戒的定义

正式的安全和内部控制确定机构的内部控制过程，包括诸如下述控制组件： • 控制环境 • 风险评估 • 控制活动 • 信息和沟通 • 监控

归档选择特殊活动、应用、系统或技术的管理决策的发行的特定存在

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的管理的信息控制框架和认知程序的基准 与项目相关的、以成本/效益分析为基础决定项目优先顺序和审批的、被批准的安全和内部控制实例的详细评价

确定：

开始怀疑管理层在贯穿机构范围内培育积极的内部控制环境承诺的虚弱的控制框架 选择机构的内部控制环境，有效地沟通其的管理失败

被分配用来明确叙述、开发、归档、发布和控制的包含内部控制环境的的资源的缺乏

测试：

在培育积极的控制方面管理层的努力，包括诸如这些关键的方面：诚实、伦理价值、行为规范、安全和内部控制、人员的能力、管理哲学和操作风格、问责制、所提供的关注和方向

雇员已经收到了行为规范并理解它

选择机构的内部控制环境的的管理层的沟通正在发生

管理层明确叙述、开发、归档、发布和控制的包含内部控制环境的的资源承诺正在发生 标准、方向、和程序的持续适当性及其适应变化条件能力的管理层的有规律地评价 管理层的监控努力正在确保适当的和足够的资源被分配以便以及时的方式执行机构的

管理层关于其内部控制环境的相关标准、方向、和程序的强制努力正确保贯穿机构的遵从性 质量哲学、和目标正决定遵从性，并与机构的法人和IT职能哲学以及和程序相一致

挑选的的IT管理、开发和运行人员正在决定质量哲学，相关的、程序和目标被理解，并被IT职能部门内所有层次所遵循

质量测量过程正在确保机构目标的满足

挑选的的管理成员在他们的评价责任之下被包括并理解安全和内部控制活动的内容（也就是说，例外报告、调和、比较，等等）

个人的角色、责任和权利在机构的所有层次上被清楚地沟通和理解

挑选的的部门评估日常监控安全和内部控制活动的程序（也就是说，例外报告、调和、比较，等等），为管理层提供反馈的过程正在发生

挑选的的系统归档确定，按照机构的和程序，系统特定的管理决策已经被归档和批准 挑选的的系统归档确定，选择特定活动、应用系统或技术的管理决策已经由高级管理层签署

7.2 人员的任职资格

7.1 人员招募和升职

7 管理人力资源（PO7）

不是最近的标准、方向、和程序

确保标准、方向、和程序贯穿机构之内遵守的不充分的管理遵从监控

IT职能部门在其质量或其有效定义、归档、维持并沟通质量哲学、和目标能力承诺方面的不足 在机构的和/或IT职能部门的安全和内部控制框架方面的弱点 缺少所需要的选择特定活动、应用或技术的特定问题的

在人员的招募和升职实践中，管理层应执行并有规律地评估所要求的过程，以确保人员的招募和升职实践依据以的标准为基础，并考虑了教育背景、经验和责任。这些过程应符合整个机构在这些方面的和程序，比如雇用、方向、培训、评估、商讨、晋升、报酬和训练等程序。管理层应确保知识和技能需求被不断地评估，并且要保证机构能够获得一个达到机构目标所需要的相匹配技能的工作队伍。

控制的IT过程： 管理人力资源 满足的业务需求：

获取和维持一个被激发和有能力的工作队伍，最大化个人对IT过程的贡献 实现路线：

在员工的招募、训练、检查、报酬、培训、评价、职位升降和解雇中，体现健全、公正和透明的人事管理实践

需要考虑的事项： 招募和升职

培训和任职要求 意识的建立

交叉培训和轮岗

雇用、检查和解雇程序 目标和可测量绩效的评估 技术和市场变化的响应

内部和外部资源的适当平衡 关键职位的继任计划 信息规范 IT资源 P 效果 * 人员 P 效率 应用 保密 技术 完整 设施 可用 数据 遵从 可靠

IT管理层应有规律地查验执行具体任务的职员，看看他们在适当的教育、培训和（或）经历的方面，是否具有所需要的资格。管理层应鼓励它的职员获得专业机构的认证资格。

获得了解：

7.4 人员培训

7.3 角色和责任

7.6 人员的调查程序

访谈：

人力资源官和挑选的人员 安全官

挑选的安全人员 IT经理

IT人力资源官 挑选的IT管理层 挑选的IT人员

7.8 工作的变更和终止

7.7 雇员工作绩效的评估

7.5 交叉培训或人员后备

IT管理层应确保他们的员工在被雇用、调离或升职之前，根据他们所在岗位的敏感性，进行安全调查程序。一个没有接受过这样安全调查的新雇员，不应安排在敏感的岗位，直到他接受了安全调查。

管理层应提供充足的交叉培训或确认的关键人员的备份，以防不测。管理层应对所有关键的职能和岗位建立持续性计划，应要求敏感岗位的人员休息一段连续的足够长度的假期，以锻炼机构应付关键人员的效效、预防和探测欺诈行为的能力。

管理层应清晰地说明职员的角色和责任，包括遵守管理和程序、道德规范和职业惯例的规定的要求。雇佣的期限和条件应强调雇员对于信息安全和内部控制的责任。

管理层应执行一个雇员绩效评估流程，借助有效的奖励机制，加强员工对于个人的业绩与机构的成功之间的关系的认识。评估应依据已经建立的标准和具体的工作职责有规律地执行。无论何时，只要是适当的，雇员应得到业绩方面的忠告或指导。

管理层应确保雇员得到雇用方向和在职的培训，以维持他们的知识、技能、能力和安全意识到所需的有效完成工作的水平。引导有效地提高员工的技术和管理技能水平的教育和培训程序应被有规律地检查。

对于工作的变化和终止，管理层应采取适当和及时的行动，以便内部控制和安全不被这样的事件削弱。

对高级和详细的控制目标进行审计：

评估控制：

评定遵从性：

挑选的与IT职能敏感位置相关的人员 获得：

与人力资源管理相关的和程序

职位描述、绩效评估形式、培训和发展形式 选择职位的人员文件和人员

证实没有满足业务目标的风险：

考虑是否：

使用标准招募和选择人员，以填补公开的职位

人员职位所需资格的说明书考虑适用的专业部门的相关需求 管理层和雇员接受工作能力过程

培训程序要与机构的已归档的关于教育和包含安全问题的总体认识的最小需求相一致 管理层应承担个人培训和职业发展的义务

技术和管理技能的缝隙被确定，针对这些缝隙，采取适当的行动 对于关键的工作职能，正在进行的交叉培训以及人员的备份发生 强制的不间断的假期发生 机构的安全检查过程是适当的

以一套标准的职位能力文件为基础，进行雇员的评估，评估以定期的方式举行 工作变化和终止过程确保机构资源的保护

人力资源管理和程序与适用的法律和规章一致

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的人力资源管理活动的基准 IT人力资源管理活动的详细评价 确定：

来自潜在/实际的工作候选人的缺陷/委屈的原因

招募、调任、晋升和终止行动中与下述相比的差异： • 没有跟随和程序

• 行动没有由适当的管理层所签署

• 行动没有以工作说明书和人员资格为基础

测试：

招募和/或晋升行动、选择标准反映职位需求的目标和关联

对于他们的工作职责或者责任区域来讲，人员具有运作的足够的知识 职位（工作）描述存在，被评价并被保持是最新的

个人文件包含雇员的机构全部教育和总体认识程序的了解的承认书 对于分配关键职能的适当的人员，正在进行的培训和教育发生 IT人员已经收到安全程序和技术方面的适当培训 IT管理层和职员知道并理解机构的和程序

安全检查调查的程序与治理隐私的适用法律相一致

业务目标的知识按照人分配给关键的IT职能，包括内部控制哲学、信息系统安全和控制概念

8.1 外部要求的评价

8.2 遵守外部要求的实务和程序

8 确保遵从外部要求（PO8）

控制的IT过程： 确保遵从外部要求 满足的业务需求：

履行法律的、法规的、契约的义务 实现路线：

识别和分析影响IT的外部要求，并采取适当的措施遵从它们 需要考虑的事项： 法律、规章和合同 追踪法律和法规的发展 对遵从性有规律的监测 安全和人类环境改造学 隐私

知识产权 信息规范 IT资源 P 效果 * 人员 效率 * 应用 保密 技术 完整 设施 可用 * 数据 P 遵从 S 可靠

人员：

• 资格不适当

• 培训和发展的机遇与能力的缝隙联系的不紧

• 缺少工作绩效的评估，或者不能支持所占据的职位和/或正被执行的任务 • 与雇佣相关联的安全调查没能跟进 • 定期的安全调查没能执行

不充分的培训程序和职员发展活动 不充分的交叉培训和关键人员的备份 没有签字的安全承认书

分配给培训和职员发展的不适当的预算和时间

职员执行关键的职能，没有指明假期和渡假天的人员时间报告

机构的实务应确保适当的纠正行为及时地被采取，以保证符合外部的要求。另外，应建立并维护确保持续不断遵从的适当程序。对此，如果需要，管理层应寻求法律意见。

机构应建立并维护外部要求检查以及协调这些活动的程序，通过持续的调查确定机构可适用的外部要求。有关IT实践和控制的法律、和其它外部部门的要求应当被检查。管理层也应评估任何有关机构总体信息要求的外部关系的影响，包括IT策略需要遵从或支持任何相关的第三方需求范围的决定。

获得了解：

8.5 电子商务

8.6 遵守保险合同

8.4 隐私、知识产权和数据流

8.3 防护和人类环境改造要求的遵从

管理层应确保保险合同的要求被完全辨认并不断地被满足。

管理层应确保遵从IT用户和员工工作环境的防护及人类环境改造的标准。

管理层应确保遵从隐私、知识产权、过境数据流和密文规则适用于机构的IT实践。

对高级和详细的控制目标进行审计：

访谈：

法律律师 人力资源官

IT职能部门的高级管理层 获得：

有关和/或外部要求（也就是说，法律、立法、指南、规章和标准）相关于外部关系和外部要求评价、保护和健康（包括工作环境改造学）遵从问题、隐私问题、信息系统安全要求、密码数据传输等方面——国内和国际

国内或国际与电子商务使用相关的“会计标准/声明” 与电子商务使用有关的征税规定 关于以下的标准、和程序： • 外部要求评价

• 保护和健康（包括工作环境改造学） • 隐私 • 安全

• 数据被输入、处理、存储、输出和传输的敏感等级 • 电子商务 • 保险

如果适用的话，与所有电子贸易伙伴以及电子数据互换（EDI）卖主签定的所有合同的拷贝件 与保险合同相关的所有IT职能的拷贝件

法律律师有关保险合同“uberrimae fodei”（以极度好的信念）需求的建议（Uberrimae fodei要求

在贸易双方之间的通讯处理以及交易信息安全和数据存储的标准方面，管理层应确保签订正式的合同，建立贸易伙伴间的协议。如果是因特网上的贸易，管理层应加强适当的控制，确保遵守当地法律和国际上广泛承认的惯例。

评估控制：

评定遵从性：

当事人各方彼此之间最大限度地披露所有风险的事实材料。假如这种感觉的良好信念没有展示出来，那么合同对于受伤害方无效的，不愉快一方不能执行合同。）

来自外部审计师、第三方服务提供者和中介的审计报告

测试：

外部要求评价是：

• 当前、全部和全面的关于法律、和规章问题 • 导致迅速的校正行动

保护和健康评价在IT职能部门之内采取，确保遵从外部要求 不能遵从保护和健康标准的问题区域被校正 IT遵从已归档的隐私和安全和程序 跨越国界传输的数据不能侵犯输出国的法律

现有的带有电子商务贸易合作伙伴的合同充分地选择机构和程序中详细说明的要求 现有的保险合同充分地选择机构和程序中详细说明的要求

在那里受规章制度的强制的所使用的加密类型（例如密钥的长度），正在使用的加密遵守规章 在那里规章或内部程序要求某项数据项被高度地保护和/或加密（例如，银行的PIN号、税款文件号、口令、军事情报），这样的保护/加密正在提供给这样的数据

由机构所布置的实际EDI的过程，确保遵从机构的和程序，遵从个人的电子商务贸易伙伴合同（如果适用的话，还包括EDI卖主合同）

考虑是否：

下列和程序到位：

• 确保与外部需求评价相关的适当的校正行动以及时的方式被采取，并且程序到位以确保持续的遵从 • 协调外部需求评价，确保校正行动以及时的方式采取，保证遵从外部需求 • 选择适当的维护、保护和健康的目标

• 确保适当的保护和健康培训和教育提供给所有的雇员 • 监控适用的保护和健康法律和规章的遵从性

• 提供隐私方面足够数量的方向/重点，以便所有的法律要求都落在其范围之内 • 通知保险公司IT环境变化的所有材料 • 确保遵从保险合同的要求

• 当新的/修改的保险合同加入时，确保更新材料

安全程序与所有的法律要求一致，并被充分地选择，包括： • 口令保护和访问软件 • 授权过程 • 终端安全措施 • 数据加密措施 • 防火墙控制 • 病毒保护

• 违背报告的及时跟进

9 评估风险（PO9）

证实没有满足业务目标的风险：

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的外部需求遵从性、EDI活动和保险合同要求的基准

确保校正行动已经被采取或者正在被执行的外部要求评价文件的详细评价

安全报告的详细评价，以便评估是否敏感/隐私信息（是否同样地由要么内部程序，要么外部规章定义）正在被给予适当的安全和秘密保护

确定：

不能由机构遵循的外部要求

在响应外部要求评价方面，重大的未解决/未更正的行动

在工作环境中不能被选择的保护和健康（包括工作环境改造学）的风险 与数据流和/或位于国境外的数据流相关的秘密和安全弱点 电子商务的故障

与贸易伙伴相关于通信过程、交易信息、安全和/或数据存储的合同中的弱点 在贸易伙伴信任关系方面的弱点 保险覆盖的弱点/失误 不遵从保险合同条款

控制的IT过程： 评估风险

满足的业务需求：

通过降低复杂性、提高目的性以及确定重要的决定因素，实现IT目标并应对威胁，进而支持管理决策 实现路线：

机构自身积极致力于风险识别和影响分析，包括多学科功能和费用效率测试，来减轻风险 需要考虑的事项： 风险管理主体和义务

不同种类的IT风险（技术、安全、持续性、法规等） 定义并沟通风险的容忍程度

根本原因分析和风险头脑风暴会议 定量和（或）定性的风险测量 风险评估方法 风险行动计划 及时的再评估 信息规范 IT资源 P 效果 * 人员 S 效率 * 应用 P 保密 * 技术 P 完整 * 设施 P 可用 * 数据 S 遵从 S 可靠

9.6 风险接受

9.4 风险测量

9.3 风险确认

9.5 风险行动计划

9.1 业务风险评估

9.7 安全装置的选择

9.2 风险评估的途径

风险评估途径应规定一个风险行动计划，以确保成本/效益控制和安全措施在持续的基础上减轻风险的暴露。风险行动计划应按照风险的避免、减轻或承受能力等方面，确定风险策略。

风险评估途径应着重于风险的基本要素和他们之间因果关系的检查上，风险的基本要素包括有形的和无形的资产、资产价值、威胁、弱点、保护装置、威胁的结果和可能性。风险辨识的过程应包括定性的，在适用的地方也要采用定量的风险排序方法，并应以管理层头脑风暴、战略计划、过去的审计和其它的评估作为输入。风险评估应考虑业务、规章、法律、技术、贸易伙伴和人力资源风险。

当寻求一个合理、适当和相称的安全和控制系统时，具有最高的投资回报率（ROI）和能快速生效的控制应被优先考虑。控制系统还应平衡预防、探测、改正和恢复措施。而且，管理层还需要沟通控制设施的目的、管理冲突的设施和监视所有控制设施的持续有效性。

管理层应建立一个通用的风险评估途径，定义它的范围和边界、所采用的风险评估的方法、责任和需要的技能。管理层应领导风险减缓解决方案的确定，并要涉及系统弱点的辨认。安全专家应领导对威胁的辩认，IT专家应负责控制的选择，结构化的方法和熟练的风险评估师是风险评估的质量保证。

风险评估途径应确保风险辨识信息的分析是由被检查区域暴露出风险的定量和（或）定性的测量造成的，机构的风险承受能力也应被评估。

根据风险辨认和测量结果、机构的、风险评估途径的本身的不确定性和实施安全控制的成本效益，风险评估途径应确保剩余风险的正式的可接受能力。剩余的风险应由适当的保险项目、签约协商的责任和自我保险抵消。 管理层应建立一个系统的风险评估框架。这样的一个框架应将相关信息风险有规律的评估与实现业务目标紧密结合，以此为基础，决定风险应怎样才能被管理到一个可接受的水平。对于新的项目，也包括修复性的项目，风险评估的过程应在全局和系统细节两个层次上进行，并保证交叉学科人员的参与。管理层应确保风险再评估的执行，并且风险评估的参考信息应根据审计、检查和确定事件的结果进行更新。

评估控制：

获得了解：

9.8 风险评估义务

访谈：

IT职能部门的高级管理层 挑选的IT人员

挑选的风险管理人员 IT服务的关键用户 获得：

相关于风险评估的和程序 业务风险评估文档 操作风险评估文档 IT风险评估文档

详细资料，以此为基础可以测量风险和风险的暴露 挑选出来的风险评估人员的个人档案 覆盖残留风险的保险 专家意见的结果 同等团体评价

来自风险管理数据库的洞察力

对高级和详细的控制目标进行审计：

在内部控制的设计和实施IT战略计划的制定以及在监督和评估机制中，管理层应鼓励风险评估作为一个提供信息的重要工具。

考虑是否：

系统的风险评估框架到位，将相关的信息风险合并到机构目标的实现上，并形成决定怎样将风险管理到一个可接受水平的基础

风险评估的方法提供规定有规律地更新的风险评估，全球的和系统特定水平两者

决定所确认的风险包括外部和内部因素，并考虑了审计、检查和确定事件结果的风险评估程序到位 全机构范围内的目标被包含在风险确认的过程中

在系统处理活动中监控变化的程序决定以及时的方式调整系统的风险和暴露 存在风险评估正在进行的监控和改善以及减轻控制的创造过程的程序 风险评估文档包括： • 风险评估方法的描述

• 重大披露和相应风险的确认 • 被选择的风险及相应的披露

可能性、频率和威胁分析技术包括在风险的确认中 风险评估人员的资格是足够的

识别和测量风险、威胁和披露的正式的定量和/或定性（或两者结合）的方法存在 计算和其它方法被用在风险、威胁和披露的测量中

风险行动计划被用在执行减轻风险、威胁和披露的适当的测量上

评定遵从性：

证实没有满足业务目标的风险：

残余风险的接受，考虑： • 机构的

• 风险识别和测量

• 合并在风险评估方法本身的不确定性 • 实施保护和控制的成本和效益 含盖抵消残余风险的保险

选择最大化返回投资的控制测量的正式的定量和/或定性的方法存在 检测、预防、纠正及所使用恢复措施之间的平衡的存在 沟通控制测量器目的的正式程序存在

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的风险评估框架的基准 用于识别、测量和减轻风险到残余风险可接受水平的风险评估方法的详细评价 确定：

没有被识别的风险 没有被测量的风险

没有被选择/管理到可接受水平的风险

过时的风险评估和/或风险评估中过时的信息 有缺陷的风险、威胁和暴露的定量和/或定性测量 不能提供成本/效益控制和安全测量的风险行动计划 残余风险的正式接受的缺乏 不适当的保险覆盖

测试：

风险评估框架按照风险评估被有规律地更新以减少风险到一个可接受的水平 风险评估文档遵守风险评估框架，并且文档要适当地准备和维持 IT管理层和人员要明白并参与到风险评估的过程中 管理层理解与风险相关的因素和威胁的可能性 有关人员理解并正式接受残余风险

发送给高级管理层的评价、所确认风险的同意以及用在减少风险活动监控上的报告是及时的 用于分析风险的方法导致风险暴露的定量或者定性（或两者结合）测量

由管理层所确认的风险、威胁和暴露以及与风险相关的属性被用来侦查特定威胁的每一个事件 风险行动计划是最新的，并包含成本/效益的控制以及减轻风险暴露的安全措施 从最高到最低的优先权存在，对每一个风险来讲，适当的响应存在： • 计划的预防性减轻控制 • 第二级的侦查控制 • 第三位的纠正控制

风险及相对的控制的情节被归档、流通并与适当的人员沟通

有关可接受的残余风险，足够的保险覆盖存在，并依照不同的威胁情节加以考虑，包括： • 火灾、洪水、地震、龙卷风、恐怖活动、其它不可预防的自然灾害 • 雇员信用责任的破裂

• 业务中断——收入的丧失，客户的丧失，等等

• 通常没有被上述IT和业务风险/持续性计划所含盖的其它风险

10.1 项目管理构架

10 管理项目（PO10）

10.3 项目组成员资格和责任

10.2 项目初始阶段用户部门的参与

控制的IT过程： 管理项目

满足的业务需求：

确定优先顺序，按时交付并控制在预算内 实现路线：

按照运行计划，对项目的确定和优先顺序进行机构；并对所承担每个项目，采纳和应用健全的项目管理技术

需要考虑的事项：

项目的业务管理层发起人地位 程序管理 项目管理能力 用户参与

任务细分、里程碑确定和阶段审准 责认的分配

里程碑和可交付的严格追踪

费用和人力预算，平衡内部和外部资源 质量保证计划和方法 程序和项目风险评估 从开发到运行的过渡 信息规范 IT资源 P 效果 * 人员 P 效率 * 应用 保密 * 技术 完整 * 设施 可用 数据 遵从 可靠

在开发、实施或修改项目的定义和授权方面，机构的项目管理框架应规定受影响的用户部门管理层的参与。

管理层应建立一个总体的项目管理框架，定义管理项目的范围和边界，以及所承担项目中采纳和应用的项目管理方法。方法应至少涵盖责任的分配、任务的划分、时间和资源的预算、里程碑、检查点和审准。

机构的项目管理框架应明确项目人员设置的原则，并且确定项目组成员的责任和权力。

10.5 项目审批

10.4 项目定义

10.12 培训计划

10.11 测试计划

10.7 项目主计划

10.6 项目阶段审批

10.8 系统质量保证计划

10.9 保证方法的计划编制

10.10 正式的项目风险管理

机构的项目管理框架应规定，在项目的工作开始之前，必须形成清晰的书面文件，定义每一个实施项目的特点和范围。

管理层应执行一个正式的风险管理程序，排除或最小化每个单个项目相关的风险（就是对于那些潜在的引起有害变化的区域或者事件，进行辨识和控制）。

管理层应确保新的或修改过的系统的实施包括质量计划的准备，它是项目主计划的一部分，并且被所有有关当事人审阅和同意。

管理层应确保，对于每一个批准的项目建立一个项目的主计划，它对于维护在整个生命周期中对项目的控制是适当的，它还包括一套监测项目生命周期中时间和费用的方法。项目计划的内容应包括对于范围、目标、所需资源和责任的描述，并应提供允许管理层测量进度的信息。

机构的项目管理框架应确保，对于每一个被提议的项目，机构的高级管理层审议了相关的可行性研究报告，以此作为是否进行这个项目的决策依据。

机构的项目管理框架应对指派的用户和IT职能部门经理做出规定，以便他们在下一阶段工作开始之前，审批项目周期的每一阶段的工作完成情况。

在项目管理框架的计划阶段期间，保证任务应被确定。保证任务应支持新的或修改的系统的合格鉴定，并确保内部控制和安全符合相关的要求。

对于每一个开发、执行和修改项目，机构的项目管理框架应要求制定一个培训计划。

机构的项目管理框架应要求为每一个开发、执行和修改的项目，建立一个测试计划。

访谈： 质量经理

项目质量经理/协调者 项目所有者/发起人 项目组组长

质量保证协调者 安全官

IT计划/指导委员会成员 IT管理层 获得：

相关与项目管理框架的和程序 相关于项目管理方法的和程序 相关于质量保证计划的和程序 相关于质量保证方法的和程序 软件项目主计划（SPMP） 软件质量保证计划（SQAP） 项目状态报告

状态报告和计划/指导委员会会议纪要 项目质量报告

评估控制：

获得了解：

10.13 实施后评价计划

对高级和详细的控制目标进行审计：

作为项目组活动的一部分，机构的项目管理框架应规定每一个新的或修改的信息系统的实施后检查计划的开发，以确认项目是否产生预期的收益。

考虑是否：

项目管理框架：

• 定义管理项目的范围和边界

• 规定评价与已批准运作计划一致性的项目请求，按照这一请求，将项目排出优先顺序 • 定义被采用并被应用到每一个所承担项目的项目管理方法，包括： • 项目计划编制 • 人员安置

• 责任和权利的分配 • 任务的分解

• 时间和资源的预算 • 里程碑 • 检查点 • 批准

• 是完整的和当前的

评定遵从性：

测试：

项目管理方法和所有的需求被一致地追随

项目管理方法与所有涉及项目的适当人员所沟通 项目的种类和范围的书面定义符合标准模板 所有者/发起者包含在项目定义、授权及与所期望的包含的所有者/发起者相一致的种类和范围由项目管理框架所规定

分配人员给项目、项目组成员的责任和权利的定义被遵循

清晰的、项目种类和范围的书面定义的证据存在，该证据在项目设计开始之前定义 相关的可行性研究已经准备并获批准

对于开发项目的每一个阶段，适当的所有者/发起者和IT管理层的批准被获得 作为SPMP所要求的那样，项目的每一个阶段正在被完成并适当地签署

• 在开发、实施或者修改项目的定义和授权方面，规定由受影响的用户部门（所有者/发起者）参与管理

• 规定一个基础，以此将职员人员分配到项目中 • 定义项目组成员的责任和权利

• 在项目设计开始之前，规定一个清晰的书面定义项目种类和范围的声明的创造 • 规定一个初始的项目定义文档，其包括项目清晰的种类和范围声明 • 包括承担项目的下列原因：

• 被补救的问题或者被改进的过程的陈述

• 按照提高实现机构目的的能力表达的项目需求的陈述 • 在相关现有的系统中的不足的分析 • 能够增长经济或者操作效率的机遇 • 项目满意的内部控制和安全的要求

• 选择方法，以此，被提议的项目的可行性研究被准备、评价并由高级管理层所批准，包括： • 项目的环境——硬件、软件、电信

• 项目的范围——首先和接下来的实施中所包括的和排除在外的

• 项目的——项目期间，我们必须要保留的，即使短期的改进机遇似乎出现 • 有项目的发起者或所有者/发起者实现的收益和成本

• 描绘方式，以此，先于项目下一阶段的进行（也就是说，编程、系统测试、交易测试并行测试，等等），开发过程（也就是说，可行性研究准备、需求的定义、系统的设计，等等）的每一个阶段都被批准

• 需要每一个项目具有SPMP的开发，并指定方式，以此维持贯穿项目生命、项目时间帧（里程碑）和预算的控制

• 遵守机构的SPMP标准，假如不存在，要使用适当的标准

• 对于每一个项目，需要SQAP的开发，并要确保其与SPMP的集成，由所有的涉及方正式地评价和同意 • 描绘方式，以此，正式的项目风险管理程序消除或者最小化相关于项目的风险 • 为每一个开发、实施和修改项目，提供测试计划的开发

• 为每一个开发、实施和修改项目，提供足够的培训所有者/发起者人员和IT人员的计划开发 贯穿每一个主要项目阶段（也就是说，软件购买、硬件购买、编程合同、网络升级，等等），预算及与之相对应的实际项目的里程碑和成本被监控并报告给高级管理层

项目的里程碑和成本超过预算的时间段和数量的部分由适当的机构管理层批准 SQAP遵守机构的SQAP标准，假如不存在，标准选择上述的

SQAP保证任务支持新的或修改的系统的鉴定资格，并确保内部控制和安全特征满足需求

所有项目所有者/发起者都要输入到SPMP和SQAP两者之中，并且所有的都要同意最终的释放物

实施以后的过程是确保新的或者修改的信息系统释放计划好的收益的项目管理框架的完整的一部分

证实没有满足业务目标的风险：

SPMP和SQAP按照项目管理框架开发和审批 SPMP和SQAP被详细说明并足够有效

被确定的强制活动/报告事实上已经被执行/产生（也就是说，“执行指导委员会会议”、项目会议、或者类似在这些会议间隙举行的会议，会议的纪要被获得并分发给有关的当事人，报告被准备并分发给有关的当事人）

按照项目管理框架，测试计划已经被开发并批准，并且是详细的和足够特效的 在测试计划中所确定的强制活动/报告事实上已经被执行/产生 用于项目的资格鉴定标准存在，并且： • 得自于目的和绩效指标 • 得自于协商一致的定量需求 • 确保内部控制和安全需求被满足

• 与本质的“什么”及与之对应的武断的“怎样”相联系 • 定义一个正式的通过/失败过程

• 具有在有限的时间周期内目标示范的能力 • 不能简单地重述设计文档的需求

项目风险管理程序被用来识别和消除，或者起码最小化与项目相联系的风险

测试计划被遵循，书面的测试评价由所有者/发起人所创造，编程和质量保证职能部门、签署过程遵照预定的

培训被影响的所有者/发起者和IT职能部门人员的书面计划被准备，允许充足的时间完成所要求的培训活动，该计划用于项目

执行后的评价计划被遵从和为该项目所设计

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的项目管理框架的基准 下列详细的评价：

• 决定所有者/发起者参与程度以及定义、授权和执行项目的总体过程适当性的项目主计划，包括： • 系统功能的定义

• 可行性，项目给定的约束 • 系统成本和收益的确定 • 系统控制的适当性

• 在其它所有者/发起者系统方面的影响和集成 • 所有者/发起者资源（人员和资金）的承诺 • 项目参与者的责任和权利的定义

• 可接受的标准既是合意的又是可实现的

• 在批准各种项目的阶段，里程碑和检查点的使用

• 项目管理过程中，Gantt图、问题日志、会议摘要等等的使用

• 决定机构的系统质量保证计划编制过程是否存在系统问题的质量报告

• 决定是否风险已经被识别和消除或者起码是最小化的正式的项目风险管理程序 • 决定十分彻底地测试了整个系统开发、执行或修改项目的测试计划的执行 • 决定系统的使用中充分地准备了所有者/发起者和IT人员的培训计划的执行 • 决定是否已经计划的及与之对应的已经交付的项目的收益被探知的执行后评价 确定： 项目： • 拙劣管理

• 超过里程碑时间

• 超越成本 • 失控的项目 • 没有授权

• 没有技术可行性 • 没有成本合理性 • 没有实现计划的收益

11.2 质量保证途径

11.1 总体质量计划

11 管理质量（PO11）

• 没有包含检查点 • 在检查点没有被批准 • 实施没有被鉴定合格

• 没有满足内部控制和安全要求 • 没能消除或减轻风险 • 没有经过彻底测试

• 没有发生，或者对正实施的系统的不充分的所需的培训 • 实施后评价没有发生

管理层应基于机构和IT的长期计划，制定和有规律地维护总的质量计划，计划应提倡改进观念并且回答什么、谁和如何做等基本的问题。

管理层应建立一个质量保证的标准的途径，含盖总的和具体项目的质量保证活动，途径应规定为实现总的质量计划而执行的质量保证活动的类型（如评价、审计、检查等等）。它还应对详尽的质量保证评价

控制的IT过程：

管理质量

满足的业务需求： 满足IT用户的需求 实现路线：

具有质量管理标准以及规定清楚开发阶段、清晰交付条件和明晰责任的系统的计划编制、执行和维护 需要考虑的事项： 质量文化的建立 质量计划 质量保证责任 质量控制实务

系统开发生命周期方法 程序和系统的测试及文档 质量保证检查和报告

最终用户和质量保证人员的培训及参与 质量保证知识库的开发 按行业规范制定标准 信息规范 IT资源 P 效果 * 人员 P 效率 * 应用 保密 * 技术 P 完整 * 设施 可用 数据 遵从 S 可靠

提出要求。

11.8 协调和沟通

11.3 质量保证计划编制

11.10 第三方实施者的关系

11.5 系统开发生命周期方法

11.7 系统开发生命周期方法的更新

11.9 技术基础设施的获取和维护框架

11.4 以IT标准和程序为依据的质量保证评价

管理层确保赋予质量保证员工责任，包括关于全面服从IT标准和程序的评价。

管理层应执行一个质量保证计划编制过程，以确定质量保证或活动的范围和时间选择。

11.6 现存技术发生重大变化的系统开发生命周期方法

对于技术基础设施的的获取和维护，应建立一个总体的框架。关于技术基础设施的一系列不同步骤（如获取、编程、归档、测试、参数设置、维护和申请安装），应由技术基础设施的获取和维护框架来治理，并与该框架一致。

管理层应执行一个过程，确保与第三方实施者之间良好的工作关系。这样一个过程应使得用户和实施者之间在验收标准、变更的处理、开发过程中的问题、用户的角色、设备、工具、软件、标准和程序方面达成一致。

如果现有的技术发生大的变化，管理层应确保系统生命周期方法被遵守，就象新技术的获取和开发的情况一样。

机构的管理层应定义和执行IT标准，并采用治理开发、获取、实施和维护计算机化信息系统和相关技术过程的系统开发生命周期方法，。挑选的的系统开发生命周期方法应适合被开发、获取、实施和维护的系统。

管理层应对它的系统开发生命周期方法进行定期的检查，以确保它的内容反映当前的被普遍接受的技术和程序。

为了IT职能部门的客户和系统实施者之间紧密的协调和沟通，管理层应建立一套流程，在此流程中，应使使用系统开发生命周期方法的结构化方法成为必须，确保满足业务需求的IT解决方案的质量规定。贯穿整个系统开发生命周期，管理层应提高具有紧密合作和沟通特点的机构工作。

11.18 质量的尺度

11.15 系统测试文档

11.13 系统测试标准

11.14 平行/飞行测试

11.19 质量保证评价报告

11.12 软件程序测试标准

11.11 软件程序文档标准

11.17 IT目标实现的质量保证评价

11.16 以开发标准为依据的质量保证评估

机构的系统开发生命周期方法应定义环境，在此基础上，新的和（或）现存的系统的平行或飞行测试将被引导。

做为每一个信息系统开发、实施或修改项目的一部分，机构的系统开发生命周期方法应规定测试系统的存档结果要保留。

机构的系统开发生命周期方法应包含已经与有关员工沟通并确定的程序文档标准。方法应确保在信息系统开发期间创建文档，或修改项目符合这些标准。

机构的质量保证途径应要求运行信息系统的执行情况检查的评价，以评估项目组是否执行了系统开发生命周期方法的规定。

做为每一个信息系统开发或修改项目的一部分，机构的系统开发生命周期方法应提供含盖整个系统的测试需求、测试确认、测试文档和测试保持力的标准。

做为每一个信息系统开发或修改项目的一部分，机构的系统开发生命周期方法应提供含盖软件单元和聚合编程测试的测试需求、测试确认、测试文档和保持力等方面的标准。

质量保证检查报告应被准备，并提交给用户部门和IT职能部门的管理层。

管理层应定义并用公认的尺度测量活动的结果，从而评估是否实现了质量目标。

质量保证途径应对于那些已经实现信息服务功能目标的特殊系统和应用开发活动的程度进行评价。

评估控制：

获得了解：

对高级和详细的控制目标进行审计：

访谈：

首席执行官（CEO）

IT职能部门计划/指导委员会成员 首席信息官（CIO） 安全官

机构质量经理

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职能部门和系统的执行者（无论是自己开发还是第三方获取）的用户之间的密切协调和沟通已经发生

• 技术基础设施的获取和维护框架与任何其它所涉及的相关步骤一起被追随 • 开发/修改以及时的方式被满意地完成

• 适当的质量保证评价报告被完成，任何所需的纠正行动被及时地采取 程序和系统文档被准备、检查、通过和维护的方式的详细评价

程序和系统测试（包括并行/穿行测试）以及文档被准备、检查、通过和维护的方式的详细评价 确保报告说明了遵守系统开发生命周期方法的规定以及新近实施/修改系统的效果和质量方面的质量保证执行后检查过程的详细评价

确定：

与长短期计划没有联系的质量计划

没有利用系统开发生命周期方法的实例，过度使用系统开发生命周期方法所发生的事情（也就是，对于小型项目太强调结构化，而对大型项目则应用不足）

系统开发生命周期方法的不适当使用之处（也就是，将自己开发所使用的系统开发生命周期方法应用到现货供应的成套软件上，而没有做相应的修改）

涉及系统开发生命周期过程的个人（包括第三方实施者）之间贫乏或根本不存在的协调和沟通的实例 在技术基础设施的获取和维护方面所追随的的不同的步骤（也就是，获取；编程、形成文档和测试；参数设置；维护和申请维修）没有被充分地跟随

程序和/或系统文档不存在、不适当或者不是最近的

程序和/或系统测试（包括并行/穿行测试）没有被执行或者不适当地执行，和/或没有形成文档或不适当地形成文档

质量保证检查/执行后检查没有被执行，或者不适当地被执行

质量保证检查/执行后检查由管理层所忽视，系统没有按照所要求的那样而实施

1.1 信息需求的定义

1.2 行动的可选择路线的表述

获取和实施

1 确定自动化的解决方案（AI1）

控制的IT过程：

确定自动化的解决方案 满足的业务需求：

确保有效和有效率的途径满足用户的需求 实现路线：

按照用户需求尺度，客观地、清晰地识别和分析可选择的机遇 需要考虑的事项：

市场上可用的解决方案的认知 获取和实施方法 用户参与和大宗买进 与企业和IT战略的结合 信息需求的定义

可行性研究（费用、收益、可选方案，等等） 功能性、可操作性、可接受性以及可支撑性需求 符合信息体系结构

成本/效益的安全和控制 供应商责任 信息规范 IT资源 P 效果 人员 S 效率 * 应用 保密 * 技术 完整 * 设施 可用 数据 遵从 可靠

机构的系统开发生命周期方法应规定，在开发、实施或修改项目被批准之前，现存的系统已经满足以及被提议的新的或修改的系统（软件、数据和基础设施）将要满足的业务需求要被明确地定义。系统开发生命周期方法应要求解决方案的功能性和操作性需求被详细说明，包括性能、安全设施、可靠性、兼容性、安全和法律。

机构的系统开发生命周期方法应规定行动的可选择路线的分析，这一行动路线要满足为建议的新的或者修改的系统而建立的业务需求。

1.8 风险分析报告

1.7 信息体系结构

1.10 审计痕迹设计

1.6 经济可行性研究

1.5 技术可行性研究

1.4 第三方服务需求

1.3 获取战略的表述

1.9 成本/效益良好的安全控制

机构的系统开发生命周期法应规定，在每一个被提议的信息系统开发、实现和修改项目中，要考虑与每一个满足已建立业务需求的可选择方案相关联的成本/效益分析。

当涉及到第三方服务供应商时，机构的系统开发生命周期法应规定对RFP（请求提议）的需求和说明书的评估。

信息系统的获取、开发和维护应在机构的IT长期和短期计划中加以考虑。机构的系统开发生命周期方法应规定软件获取战略计划，定义软件获取是现货购置、内部开发、通过签约开发，还是强化现有的软件，亦或是上述这些的结合。

当解决方案正被确认并进行可行性分析时，管理层应确保对企业数据模型的关注。

为了满足被提议的新的或者被修改的信息系统项目而建立的业务需求，机构的系统开发生命周期法应规定每一个可选择方案的技术可行性的检查。

管理层应确保安全的成本和效益以货币以及非货币的口径被仔细地检查，保证控制的成本不超过收益，这个决定需要正式通过管理层的同意。所有的安全需求应作为整个信息系统业务案例的一部分在项目的需求阶段被辨认、论证、同意并要建立文档。应对业务持续性方面的安全需求做出定义，保证拟定计划的启动、回退和恢复过程能被提议的解决方案所支持。

在每一个被提议的信息系统开发、实现或修改项目中，机构的系统开发生命周期法应规定安全威胁、潜在的弱点和影响以及减少或消除确定风险的切实可行的安全和内部控制安全措施的分析和文档。这些的实现要与总体的风险评估框架相一致。

机构的系统开发生命周期方法应要求审计痕迹的适当机制，保证其可用性或者可以在确定并选择的解决方案上开发。这个机制应提供防止敏感数据（例如用户的ID）不被发现和误用的能力。

软件产品的获取应遵从机构的采购。

1.18 技术的验收

1.17 设施的验收

1.13 采购的控制

1.14 软件产品获取

1.11 人类环境改造

1.12 系统软件的选择

1.15 第三方软件的维护

1.16应用程序开发的签约

对于来自第三方供应商带有用户许可证的软件，管理层应要求供应商具有适当的程序来验证、保护和维持该软件的完整性。应在有关递交产品的维护协议书中，考虑产品的支持。

管理层应开发并执行一个集中采购办法，这种办法描述了一套信息技术相关的硬件、软件和服务采购的共同程序和标准。产品在投入使用和做财务结算之前，应当进行检查和测试。

管理层应确保在由IT职能部门承担的信息系统开发、执行和项目变更中，关注与自动化解决方案的引入密切相关的人类环境改造问题。

管理层应确保被提供的详细技术的验收计划要与供货商在合同中相一致，这一计划定义验收的程序和标准。另外，计划中规定的验收测试应包括检查、功能性测试、工作负荷试验。

管理层应确保被提供设施的验收计划与供货商在合同中定好的协议相一致，这一计划要定义了验收的程序和标准。另外，验收测试应被执行，以保证位置和环境符合合同所描述的要求。

机构的系统开发生命周期方法应规定，合同程序开发服务的流程必须具有来自IT职能部门的一个指定成员的书面申请。合同应规定在验收之前，软件、文档和其它交付件必须经过测试和评价。另外，合同应要求在付款和最终产品正式承认以前，全部合同程序开发服务的最终产品必须由IT职能部门的质量保证小组和其它有关人员（如用户、项目经理等），按照相关标准而进行测试和评价。合同的详细说明中的测试应由系统测试、集成测试、硬件和组件测试、程序测试、负载和压力测试、参数调整和性能测试、回归测试、用户接受测试以及最终的整个系统的穿行测试组成，以避免任何想不到的系统失败。

管理层应确保由IT职能部门执行一个标准程序，以辨别所有的潜在的可以满足操作需求的系统软件。

评估控制：

获得了解：

对高级和详细的控制目标进行审计：

访谈：

首席信息官（CIO） 安全官

IT高级管理层

项目所有者/发起人 合同管理层 获得：

与系统开发生命周期以及软件获得相关的和程序 IT的目标和长短期计划

挑选的项目文档，包括需求定义、选择性分析、技术可行性研究、经济可行性研究、信息体系结构/企业数据模型分析、风险分析、内部控制/安全成本效益研究、审计痕迹分析、人类环境改造学的研究以及设施和特定技术接受计划和测试结果

与软件购买、开发或维护相关的挑选的合同

考虑是否：

和程序存在，要求：

• 在开发、实施或修改项目被通过以前，现有系统感到满意的或者被提议的新的或修改的系统满意的用户需求被清晰地定义

• 先于开发、实施或修改项目的通过，用户需求文档以书面的形式由认知的所有者/发起者检查并通过

• 解决方案的功能和操作需求应该感到满意，包括性能、保护、可靠、兼容、安全和法律 • 先于选择一个又一个的软件解决方案，用户需求的可选择的解决方案被研究并被分析 • 在最终的选择决策作出之前，满足特定系统开发或修改项目用户需求的商业软件包的识别

• 依照现货供应、内部开发、通过合同，或者升级现有的软件，或者所有这些方式的结合，软件产品获取的选择被清晰地定义

• 建立起来用于被提议新的或修改系统项目的满足用户需求的每一个可选择的技术可行性研究被准备、分析并由认识的所有者/发起者通过

• 在每一个被提议的系统开发、实施和修改项目中，与每一个选择相关的被考虑满足用户需求的成本和收益的分析要被执行

• 先于作出是否开发或修改被提议的新的或者修改的系统项目的决策，经济可行性研究被准备、分析并由认识的所有者/发起者通过

• 当解决方案的可行性被识别和分析时，要关注企业的数据模型

• 在每一个被提议的系统开发、实施或修改项目中，分析被准备，安全威胁、潜在的弱点和影响以及为减少或消除确定风险的切实可行的安全和内部控制保护要制成文档

• 安全的成本和效益被仔细地检查以保证控制的成本不超过收益 • 成本/效益研究的正式的管理层签署

• 在项目的设计阶段，适当的审计痕迹和控制被要求建造到所有被提议的新的或修改的系统之中 • 审计痕迹和控制，在没有危及系统安全的前提下，提供保护用户免除他们的身份被其他人发现并误用的可能性（例如，通过提供匿名、使用假名、解开能力或者不可观察）

评定遵从性：

测试：

令现有系统满意并令被提议的新的或修改的系统满意的用户需求已经被清晰地定义、检查，并在项目的开发、实施或修改之前，由认识的用户以书面的形式通过

解决方案的功能和操作需求令人满意，包括性能、保护、可靠、兼容、安全和法律 现有系统中的所有弱点和处理的不足已经被识别出来，并打算由被提议的新的或修改的系统完全地选择并解决

建立在被提议的新的或修改的系统之上的满足用户需求的可选择的行动路线已经被适当地分析 满足特定系统开发或修改项目需要的商业软件包已经被适当地确定和考虑 与每一个可选择相关的所有的可以确认的成本和收益已经被适当地支持，并作为经济可行性研究所需的部分

同解决方案可行性被确认和分析一样，应注意信息体系结构/企业的数据模型

安全威胁、潜在弱点和影响、减少或消除确定风险的切实可行的安全和内部控制措施的风险分析报告是正确和全面的

在系统设计的文档中，安全和内部控制问题已经被适当地说明

带着抵消成本的适当收益，适当位置上的控制和计划是足够的管理层审批 审计痕迹的适当机制是可能的，或者可以为所确定和选择的解决方案而开发

在屏幕的版面、报告格式、联机帮助工具等等的系统设计和开发期间，提高最终用户技能的用户的友好设计已经被考虑

系统设计和开发期间，人类环境改造学问题已经被考虑

先于设计和开发，用户的性能问题（也就是，系统的响应时间、下载/上载能力、特别报告）已经包括在系统的需求说明书中

• 每一个被提议的系统开发、实施或者修改项目要注意与自动化系统的引进相关联的人类环境改造学问题

• IT管理层识别满足运营需求的所有潜在的系统软件程序 • 先于产品的使用和财务的结算，产品被检查和测试

• 软件产品的获取跟随机构为提议申请的创造、软件产品供应商的选择和合同谈判而设立的框架的获取

• 对于从第三方供应商获取而来的有许可证的软件，供应商具有适当的程序验证、保护并维护软件产品的完整权利

• 合同编程服务的获取用来自指定IT职能部门成员的书面服务请求来证明是正当的 • 设施的接受计划与供应商在合同中的一致，这一计划定义了接受程序和标准

• 在为相关工作支付款项以及最终产品通过之前，完成的合同编程服务的最终产品，按照IT质量保证小组和其它有关当事人的相关标准，被测试和检查

• 特定技术的接受计划与供应商在合同中的保持一致，这一计划定义了接受的程序和标准 • 合同编程服务的获取用来自指定IT职能部门成员的书面服务请求来证明是正当的 按照总体的风险评估框架实施风险分析

分配或维持输出和输入数据并正确解释它们的安全属性的机制存在

管理层已经开发并实施了的获取方法，描述了一套公共的跟在IT硬件、软件和服务获取之后的程序和标准

先于接受，合同规定软件、文档和其它交付物要屈从于测试和检查

测试包括在合同的规范中，由系统测试、集成测试、硬件和组件测试、程序测试、负载和压力测试、调整和性能测试、衰退测试、用户接受测试以及最终的整个系统的穿行测试组成，以避免想不到的失败

设施的接受测试被实施，以保证适应性和环境满足合同中详细说明的需求 特定的技术接受测试应该包括检查、功能性测试和工作负载试验

证实没有满足业务目标的风险：

满足操作需求的所有潜在系统软件编程的IT功能的确认

在IT相关硬件、软件和服务的获取中，IT功能遵循一套公共的程序和标准 先于购买产品的使用和财务结算，要进行检查和测试

假如适用的话，软件购买协议允许用户具有拷贝程序源代码的条款 软件产品的升级、技术的更新和维修要在获取文档中详细说明 第三方软件维护包括软件产品的完整性的确认、保护和维护的需求

订立合同的编程人员的工作服从于同一层次的测试、检查和签署，作为机构自己的程序员的要求 机构的质量保证职能负责由订立合同的程序员执行工作的检查和签署 设施接受计划的适当性和完整性正在发生，包括接受程序和标准

特定技术接受计划的适当性和完全性，包括检查、功能测试和工作负载试验

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的满足自动化解决方案的用户需求的确认的基准

详细的评价：

• 满足用户需求的自动化解决方案的确认（包括用户需求的定义；可选择行动路线的明确表达；商业软件包的确认；技术可行性、经济可行性、信息体系结构和风险分析研究的执行）

• 安全、内部控制（包括用户友好设计的考虑、人类环境改造学，等等）以及审计痕迹的可能，或者具有为所确定和选择的解决方案进行开发的能力

• 系统软件的选择和实施

• 机构现有软件的获取和程序，内部控制充足性和遵从性 • 第三方维护正在被管理的方式

• 合同应用编程已经被监控和管理的方式

• 确保适应性和环境测试满足合同中详细说明的需求的设施接受过程

• 确保检查、功能测试和工作负载试验满足合同中详细说明的特定技术的接受过程 确定：

机构的系统开发生命周期方法的不足 不能满足用户需求的解决方案 系统开发努力：

• 没有考虑可选择的行动路线，因此造成更昂贵的解决方案 • 没有考虑已经以最少的时间和最小的成本实施的商业软件包

• 没有考虑可选择的技术的可行性，或者不适当地考虑了被选择的解决方案的技术的可行性，造成的结果是不能按照最初的设计来实施解决方案

• 在经济的可行性研究中，制造了不正确的假定，造成了选择错误的行动路线的结果 • 没有考虑信息体系结构/企业数据模型，结果选择了错误的行动路线

• 没有引导健壮的风险分析，因此，要么没有充分地确认风险（包括威胁、潜在的弱点和影响），要么没有确认减少或消除确定风险的适当的安全和内部控制

解决方案：

• 由于控制和安全的成本/效益的不适当的检查，要么产生过度的控制，要么处于过度的控制之下 • 没有适当的审计痕迹

• 没有考虑用户的友好设计和人类环境改造学问题，因此，结果是不可避免的数据输入错误 • 不能跟随机构已建立的获取方法，因此，结果是由机构负担额外的成本 缺乏所需的的系统软件

由于不适当的参数设置，造成系统软件的效率低下

第三方软件维护没有真正做到合同上的条款，结果是在满足机构的使命和/或目的方面对其产生不利

2.1 设计方法

2.2 现有系统的重大变更

2 获取和维护应用软件（AI2）

的影响

合同上的应用编程没有真正做到合同上的条款，结果耗费了机构额外的金钱，延误了系统的实施，等等

设施没有进行全面适应性环境测试而接受的情况，结果是不能满足用户的需求和/或没有遵从合同条款

特定的技术被接受，但是，监督、功能性测试和工作负载试验没能充分地执行，结果是技术不能满足用户的需求和/或不能遵从合同条款

任何系统的失败

对于任何新的信息系统开发项目，机构的系统开发生命周期方法应提供适当的程序和技术，包括与系统用户的密切联系，应用到创建设计规格说明书当中，而且需要对照用户的需求对设计规格说明书进行效验。

管理层应确保证现有系统发生重大变更时，类似于新开发系统一样。

控制的IT过程： 获取和维护应用软件 满足的业务需求：

提供自动化的功能，该功能能够有效支持业务过程 实现路线：

用详细、精确的语句定义功能性和操作性的需求，清晰的可交付使用的阶段性实施 需要考虑的事项： 功能性测试和验收 应用控制和安全要求 文档要求

应用软件生命周期 企业信息体系结构 系统开发生命周期方法 人机接口

程序包的用户化定制 信息规范 IT资源 P 效果 人员 P 效率 * 应用 保密 技术 S 完整 设施 可用 数据 S 遵从 S 可靠

2.9 人机接口

2.8 接口的定义

2.3 设计的审批

2.6 源数据采集的设计

2.7 输入需求定义和建档

2.5 软件程序规格说明书

2.11 输出需求定义和建档

2.4 文件需求的定义和建档

2.10 处理需求的定义和建档

机构的系统开发生命周期方法应要求，对于每个信息系统开发或修改项目，必须准备详细的书面程序规格说明书。方法应进一步确保程序规格说明书与系统设计说明书保持一致。

对每一个信息系统开发或修改项目，机构的系统开发生命周期方法应规定一个适当的程序，用于对文件格式进行定义并建档，这样的程序应确保数据字典规则被遵守。

机构的系统开发生命周期方法应规定所有外部和内部的接口被适当地详细说明、设计并要建档。

对于每一个信息系统开发或者修改项目，机构的系统开发生命周期方法应要求存在适当的输出需求的定义和建档的机制。

对于每一个信息系统开发或者修改项目，机构的系统开发生命周期方法应要求存在适当的处理需求的定义和建档的机制。

机构的系统开发生命周期方法应规定用户和机器之间的接口的开发，这一接口应易于使用和自我说明（借助在线帮助功能）。

对于每一个信息系统开发或者修改项目，机构的系统开发生命周期方法应要求适当的输入需求定义和建档的机制存在。

对于每一个信息系统开发或者修改项目，机构的系统开发生命周期方法应要求详细说明适当的数据采集和录入机制。

机构的系统开发生命周期方法应要求，所有的信息系统开发和修改项目的设计规格说明书应得到管理层、影响到的用户部门的检查和批准，如果需要，还应提交机构的高级管理层。

获得了解：

2.12 可控制性

访谈：

首席信息官（CIO） 安全官

IT高级管理层

项目所有者/发起者 获得：

2.15 应用软件的测试

2.17 系统设计的重新评估

2.13 关键设计因素的可用性

2.16 用户参考手册和支持资料

2.14 应用程序软件中的IT完整性的装置

在用户批准之前，单元测试、应用测试、综合测试、系统测试以及负载和压力测试应按照项目测试计划和已建立的测试标准执行。应当采取适当的措施防止测试期间敏感信息的暴露。

机构的系统开发生命周期方法应规定，要准备适当的用户参考资料和支持手册（最好是电子版的），作为每一个信息系统开发或修改项目的一部分。

机构应建立程序，确保应用程序在适用的地方内置特定的装置，例行校验软件所实现的任务，帮助确保数据的完整性，并通过退回重来或其它手段，来提供完整性的恢复。

机构的系统开发生命周期方法应规定，可用性应当尽可能早地在新的或修改的信息系统的设计过程中被考虑。应对可用性进行分析，如果必要，通过可维护性和可靠性的改进来增加可用性。

对于每一个信息系统开发或者修改项目，机构的系统开发生命周期方法应要求确保内部控制和安全需求的适当机制被详细描述。方法应进一步明确信息系统的设计包括了应用的控制，保证输入、处理、输出的准确性、完整性、及时性和授权。敏感性评估应在系统开发或修改的开始时执行。为了将安全的概念尽早地结合到设计中去，被开发或修改系统的基本安全和内部控制方面的问题应同系统的概念设计一起被评估。

机构的系统开发生命周期方法应确保，在系统开发或维护期间，无论什么时候发生重大的技术和（或）逻辑的差异，系统设计必须被重新评估。

对高级和详细的控制目标进行审计：

评估控制：

与系统开发生命周期方法相关的和程序 IT目标和长短期计划

挑选的项目文档，包括设计的通过、文件需求的定义、编程的说明书、源数据采集设计、输入需求的定义、用户/机器的接口、处理需求的定义、输出需求的定义、内部控制/安全的需求、可用性需求、IT完整性的规定、应用软件的测试计划和结果、用户参考资料和支持资料以及系统设计的再评估

考虑是否：

确保下述的和程序：

• 机构的系统开发生命周期方法适用于新系统的开发和现有系统的较大变化两者，并且用户要参与 • 在依照用户需求创造设计说明书和校验设计说明书中，与用户的密切联络

• 在现有系统较大变化的事件中，与新系统的开发情况一样，类似于系统开发生命周期过程被遵循 • 当所有新的系统开发和修改项目适当时，设计说明书由管理层、受影响的用户部门和机构的高级管理层签署

• 为每一个新的系统开发或修改项目定义文件格式并要将其制成文档的适当的过程正在被应用，包括考虑了数据字典规则的需求

• 为每一个信息开发或修改项目准备详细的书面编程说明书，这些编程说明书要与系统设计说明书一致

• 每一个新的系统开发或修改项目的数据的采集和录入的适当机制要被详细地说明 • 每一个新的系统开发或修改项目的输入需求的定义和归档的适当机制存在

• 用户和机器之间的接口的开发存在，该接口容易使用并能够自己形成文档（借助于在线帮助功能） • 每一个新的系统开发或修改项目的内部和外部接口的定义和归档的适当机制存在 • 每一个新的系统开发或修改项目的处理需求的定义和归档的适当机制存在 • 每一个新的系统开发或修改项目的输出需求的定义和归档的适当机制存在

• 每一个新的系统开发或修改项目确保内部控制和安全需求的适当机制被详细说明

• 内部控制和安全需求包括应用控制，它们保证输入和输出的精确性、完整性、及时性和授权

• 在新的或修改的系统的设计过程中，在尽可能早的阶段，考虑可用性，这一考虑应该分析，如果必要，通过可维护性和可靠性增进改进

• 应用编程包含日常由软件执行的校验任务的规定，通过“全部重来”或者其它手段，提供完整性的恢复

• 在由用户通过以前，按照项目测试计划和已建立的测试标准测试应用软件

• 准备足够的用户参考资料和支持手册（电子版最好）作为每一个系统开发或修改过程的一部分 • 系统开发或维护期间，无论何时发生重大的、技术的和/或逻辑差异，都要对系统设计进行再评估 系统开发生命周期方法要确保用户参考资料和支持资料以精确及时的方式更新

在新的系统开发或修改的开始期间，敏感性评估由被执行的系统开发生命周期方法所要求

系统开发生命周期方法要求新的被开发的或者修改的系统的基本安全和内部控制方面与系统的概要设计一道被评估，以便尽早将安全的概念集成到设计中

逻辑安全和应用安全问题由被选择并包括在新的系统的设计或现存系统的修改中的系统开发生命周期方法所要求

安全和内部控制方面的评估是以健全的框架为基础的

在与人类操作员的交互或控制框架中，人工智能系统被放置，以便确保生死攸关的决策被通过

应用测试期间所使用的敏感信息的披露，要么由强大的访问减轻，要么由利用所使用的历史数据失去个性处理减轻

评定遵从性：

证实没有满足业务目标的风险：

测试：

在系统开发生命周期过程中，用户的参与是高的

机构的系统开发生命周期方法确保适当地说明所有的系统设计问题（也就是，输入、处理、输出、内部控制、安全、灾难恢复、响应时间、报告、变更控制，等等）的过程到位

关键的系统用户要卷入系统设计过程

先于项目的下一阶段的开始工作，设计检查和通过过程确保所有的问题已经被解决 确保现有系统的重要变化使用类似新的系统开发的系统开发生命周期方法而开发 确保系统的编程只有在得到适当的设计签署才能开始的设计签署程序到位 系统文件需求和文档以及数据字典都要与标准相一致 用户在最终文件说明书上的签署发生 编程说明书与系统设计说明书一致 数据采集和数据录入设计说明书匹配 用户/机器接口设计说明书存在

用户/机器说明书容易使用，自己形成文档（使用联机帮助工具）功能被放置到位 内部和外部接口被制成文档 处理需求在设计说明书中 输出需求在设计说明书中

内部控制和安全需求在设计说明书中

应用控制需求设计说明书保证输入和输出的精确性、完整性、及时性和授权

内部控制和安全需求尽可能早地包括在系统的概要设计中（无论是新系统还是正在修改的系统） 安全官积极地参与新的系统或系统修改项目的系统的设计、开发和实施过程

如果适用的话，系统设计决定是否改进的可用性/可靠性已经按照时间和先前方法更有效的程序被量化

应用编程规定例行公事地校验由软件所执行的任务，以帮助确保数据的完整性 存在已经建立的测试标准

项目测试计划和用户通过过程存在

用户参考资料和支持材料以及联机帮助工具是可利用的

“帮助工作台”正在有效地帮助用户用户选择更复杂的处理问题

逐步升级的“帮助工作台”问题的过程包括追踪、监控以及诸如此类问题向适当IT管理层的报告 需要更新用户文档的适当的机制 用户文档变更的沟通正在发生

无论何时发生重大的技术和/或逻辑差异，在评估过程都会发生

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的获取和开发应用软件的成本的基准 以下挑选的事项的详细评价：

• 评估设计说明书足够性以及对这些设计说明书遵从性的系统设计文档

• 新的系统开发或修改项目决定是否设计说明书文档已经由IT职能部门和受影响的用户职能部门的管理层，如果适用，也包括机构的高级管理层，检查和通过

• 确保文件需求（起码是下列列出的文件）被清晰地由项目实施组所理解的软件文档，每个系统和用户需求以及机构的数据字典规则正在被结构化：

• 主文件 • 交易

控制的IT过程：

获取和维护技术基础设施 满足的业务需求：

提供支持业务应用的适当平台

• 命令 • 编程 • 控制 • 表 • 报告 • 打印 • 日志 • 传输

• 确保在流程图/流程图表中确定的文件、编程、源数据采集装置、输入、用户/机器接口、处理步骤和输出对应于各种不同的系统设计说明书的新的系统开发和修改项目

• 决定无论何时重大的技术和/或逻辑的差异被确定，有效的系统设计再评估过程就发生的新的系统开发和修改项目

• 决定任何技术设计差异或功能变化存在需要的新的系统开发和修改项目

• 评估在设计中尽可能早的时间确保输入和输出的精确性、完整性、及时性和授权以及安全概念的集成的内部控制和安全规定的适当性的新的系统开发和修改项目以及系统概要设计

• 按照改进的最终用户的可用性和可靠性以及IT维护人员的可维护性评估设计的新的系统开发和修改项目

• 评估应用编程数据完整性校验的适当性的项目

• 确保用户参考资料是最近的、与系统文档一致并全面满足用户需求的新的系统开发和修改项目 下列效果的详细评价：

• 按照用户设计说明书，确保编程是书面的的编程说明书过程 • 按照用户设计说明书，确保编程是书面的的输入说明书过程

• 按照用户设计说明书，确保编程是书面的的用户/机器接口说明书过程 • 按照用户设计说明书，确保编程是书面的的处理说明书过程 • 按照用户设计说明书，确保编程是书面的的输出说明书过程

机构测试标准的详细评价以及挑选的新的系统开发和修改项目的相关测试计划的实施 用户对系统、它的报告、用户文档和参考资料、帮助工具等等的满意度的详细评价 确定：

用于新的系统开发或修改项目的机构的系统开发生命周期方法的不足 没有反映用户需求的设计说明书

文件需求与机构的数据字典规则不一致

包含不适当的定义文件、编程、源数据选择、输入、用户/机器接口、处理、输出和/或可控性需求的新的系统开发或修改项目

在设计过程中没能考虑可用性的新的系统开发或修改项目

在新的系统开发或修改项目中，应用编程软件中的数据完整性的不足

导致不能正确地处理数据、不正确地报告数据等等的系统实施的机构测试标准上的不足 在新的系统开发或修改项目上的测试计划的不足

在新的系统开发或修改项目上用户参考资料和支持材料方面的不足

在系统开发或维护期间已经发生的，不能导致系统设计再评估的，因此运行不正确或者导致无效率、无效果和不经济的系统补丁的重大技术和/或逻辑不足

3 获取和维护技术基础设施（AI3）

3.3 系统软件安全

3.5 系统软件的维护

3.4 系统软件的安装

3.2 硬件的预防性维护

3.1 新硬件和软件的评估

对新的或者修改的系统来讲，硬件和软件选择标准应基于功能规格说明书，并应区分强制的和可选择的要求。应设定一个程序，评估新的硬件和软件对全部系统性能的任何影响。

IT管理层应确保所安装系统软件的设置不会危及已经存储在系统中的数据和应用程序的安全。应重点关注系统软件参数的设置和维护。

应执行适当的程序，确保系统软件的安装与机构的技术基础设施的获取和维护框架一致。在被授权应用于生产环境之前，应进行测试。一个于用户和开发者的小组应控制数据库中的程序和数据的移动。

应执行适当的程序，确保系统软件按照技术基础设施获取和维护框架的要求而维护。

IT管理层应确定日常的和定期的硬件维护的时间表，以减少性能故障的频率和影响。

实现路线：

明智的硬件和软件的获取、软件的标准化、硬件和软件性能的评估以及一致性的系统管理 需要考虑的事项：

遵从技术基础设施的方向和标准 技术评估

安装、维护与变更控制 升级、转换和移植计划

内部和外部基础设施和（或）资源的使用 供货商责任和关系 变更管理

所有者的总成本 系统软件安全 信息规范 IT资源 P 效果 人员 P 效率 应用 保密 * 技术 S 完整 设施 可用 数据 遵从 可靠

评估控制：

获得了解：

3.6 系统软件变更控制

3.7 系统实用程序的使用和监控

为了利用、监控以及评估系统实用程序的使用，应执行适当的和技术，使用敏感软件实用程序的责任应清楚地定义，并被开发者所理解，实用程序的使用应被监控并记入日志。

访谈：

IT计划/指导委员会 首席信息官（CIO） IT高级管理层 获得：

与硬件和软件相关的获取、实施和维护的和程序 高级管理层指导的角色和责任 IT目标和长短期计划 状况报告和会议纪要 供应商的硬件和软件文档

硬件和软件的租赁合同或租借协议

应执行适当的程序，确保系统软件的变更控制符合机构的变更管理程序。

对高级和详细的控制目标进行审计：

考虑是否：

确保下述的和程序存在：

• 正式的评估计划要准备，以评估新的硬件和软件对系统的整体性能的影响 • 访问系统软件的能力以及因此而中断运行的信息系统环境被

• 系统软件的建立、安装和维护不能危及存储在系统中的数据和程序的安全 • 系统软件的参数要被选择，以确保存储在系统中的数据和程序的完整性 • 按照技术基础设施获取和维护框架，安装和维护系统软件

• 系统软件供应商对他们的软件及其这些软件的所有修改提供完整性保证的声明

• 在系统软件引入到生产环境之前，其全面的测试（也就是，使用系统开发生命周期方法）正在发生 • 提供系统软件的供应商的安装口令在安装时变化以及系统软件的变化，要依照机构的变更管理程序 预防性的硬件维护（包括由IT职能部门操作的和受影响的用户职能部门操作的两者）的和程序存在，以减少性能失败的频率和影响

供应商为每一个由IT职能部门和受影响的用户职能部门操作的硬件装置描述的预防性维护步骤和频率被追随

使用和监控系统实用程序使用的和技术存在

使用敏感软件实用程序的责任被清晰地定义，并由程序员所理解，实用程序的使用被监控并要做日志

评定遵从性：

控制的IT过程： 开发和维护程序 满足的业务需求：

证实没有满足业务目标的风险：

4 开发和维护程序（AI4）

测试：

对所有的系统软件（包括所有的修改），存在提供系统软件完整性保证声明的供应商 性能评估的结果要与系统需求作比较 性能评估的正式通过过程存在

预防性的维护时间表确保预定的硬件维护不会对关键或敏感的应用产生负面影响

预定的维护确保不被排在高峰的工作负荷期间，IT职能部门和受影响的用户组的操作是十分的灵活，以适应日常预定的预防性维护

IT运行时间表确保足够的准备，以适应不按时间表维护的预先的硬件停工期

系统软件参数确保由适当的IT人员选择正确的参数，以确保存储在系统中的数据和程序的完整 访问被仅对IT职能部门中的有限数量的操作员

系统软件按照技术基础设施获取和维护框架进行安装和维护 对于所有系统软件，在系统软件被授权引入生产环境之前，全面的测试（使用系统开发生命周期方法）发生

所有提供系统软件的供应商的安装口令在安装时被改变 所有的系统软件的变化依照机构的变更管理程序被控制

系统管理（例如，系统和网络用户的增加；数据库的建立和备份；数据存储空间的分配；系统的优先权；等等）被仅在IT职能部门内的有限数量的操作员身上

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的硬件和软件的获取、实施和维护的基准 下述的详细评价：

• 挑选的操作系统以及系统开发或修改项目的文档，决定是否存在系统正式的硬件和软件的性能需求（包括交易量的资料、处理和响应时间、文件和数据库的大小、网络的流量以及通信协议的兼容性）

• 硬件的维护实务，决定维护是否按照供应商指南以及不会对系统的整体性能造成影响的预定时间表而执行

• 挑选的操作系统以及开发或修改之中的系统的文档，评估绕过由系统软件所提供的现有逻辑安全访问的潜在能力

• 系统软件的安装、维护和变更控制，确保遵从技术基础设施的获取和维护框架，系统的完整性被维护

确定：

已经影响了系统的整体性能的性能评估

已经影响了系统的整体性能的预防性的维护问题

在系统软件的建立、安装和维护中的弱点（包括选择了不适当的系统软件的参数），这些弱点已经危及存储在系统中的数据和程序的安全

系统软件测试中的弱点，这些弱点可能会危及存储在系统中的数据和程序的安全

系统软件变更控制过程中的弱点，这些弱点可能会危及存储在系统中的数据和程序的安全

访谈：

获得了解：

4.4 培训资料

4.3 操作手册

4.2 用户程序手册

4.1 操作需求和服务水平

机构的系统开发生命周期方法应确保操作需求和服务水平的及时定义

确保应用软件和技术解决方案的适当使用到位 实现路线：

通过结构化的方法，开发用户和操作程序手册、服务需求和培训材料 需要考虑的事项： 业务过程的再设计

由于其它技术交付而产生的处理程序 适时的开发

用户程序与控制 操作程序与控制 培训资料 变更管理 信息规范 IT资源 P 效果 * 人员 P 效率 * 应用 保密 * 技术 S 完整 * 设施 可用 数据 S 遵从 S 可靠

作为每一个信息系统开发、执行或修改项目的一个部分，机构的系统开发生命周期方法应确保开发出适当的培训资料。这些材料应以系统的日常使用为中心。

作为每一个信息系统开发、执行或修改项目的一个部分，机构的系统开发生命周期方法应规定适当的操作手册要预先准备好并保持更新。

作为每一个信息系统开发、执行或修改项目的一个部分，机构的系统开发生命周期方法应规定适当的用户程序手册要预先准备好并被更新。

对高级和详细的控制目标进行审计：

评估控制：

评定遵从性：

IT应用开发 IT维护 IT变更控制 IT运行

IT人力资源/培训 IT质量保证管理

挑选的信息系统资源的用户 获得：

与下述相关的机构和程序：战略计划和业务目标、信息系统计划和应用开发

与系统开发相关的IT和程序，包括：组织机构图、系统开发生命周期方法、容量计划、用户和运行手册、培训资料、测试和向生产状况的移植以及业务恢复/意外事故计划文档

考虑是否：

用历史的可能的性能统计和用户关于预期的增加/减少的输入，决定运行需求 服务水平和性能预期是足够的详细，以允许追踪、报告和改进的机会

使用历史的性能、用户的调整以及行业的基准，决定运作需求和服务水平 在新系统的计划编制中，服务水平和处理需求是完整的一个步骤 用户程序手册、操作手册和培训资料被作为每一个信息系统开发、实施或修改项目的一个部分而开发，并要保持更新

测试：

操作需求到位，并要反映操作和用户预期两者 操作性能被测量、沟通，不足之处要纠正 操作人员和用户要知道性能需求

操作人员要有所有系统的操作手册，并在他们的职责范围内处理 所有的从应用开发到生产的程序的动作要求操作手册的更新或创造 所有应用的用户培训手册存在，并普遍地反映应用的功能

所有当前的和任何新的系统的培训手册存在，并令用户满意，反映系统日常实践的使用 用户手册确定的内容包括，但并不限于此： • 系统和环境的概述

• 所有系统的输入、编程、输出以及与其它系统集成的说明 • 所有数据输入画面和数据显示画面的说明 • 任何和所有错误信息以及适当响应的说明

证实没有满足业务目标的风险：

5 系统的安装和鉴定（AI5）

控制的IT过程： 系统的安装和鉴定 满足的业务需求：

检验和确认解决方案满足预期的目标 实现路线：

非常正式的安装移植、转换和验收计划的实现 需要考虑的事项：

用户和IT操作人员的培训 数据转换

反映真实环境的测试环境 鉴定合格

在实施之后的评价和反馈 最终用户参与测试 持续的质量改进计划 业务持续性要求

• 问题逐步升级程序和/或资源

操作员手册定的内容包括，但并不限于此： • 系统名、程序名、执行的顺序

• 所有文件名的输入、处理以及输出和媒介格式的定义 • 每天、每周、每月、每季、每年终等等的运转时间表 • 要求由操作员输入的控制台命令和参数 • 控制台差错信息和响应

• 在不同的点或者反常终止时的备份、重新启动、恢复程序 • 特殊的输出表格或程序；报告/输出的分发 • 如果适用，紧急情况的修理程序

应用文档、用户和操作手册以及培训的不断发展的维护正在发生

执行：

为了选择系统开发项目，要评价文档并通过以下内容： • 考虑将来的需求和用户的服务水平

• 任务和交付的创造以及用户手册的维护 • 任务和交付的创造以及操作手册的维护

• 理解和使用新的系统或新的修改的用户培训的任务和交付

确定系统开发努力充足性的用户访谈，包括开发的手册和提供的培训 用户和操作手册两者的流通性和不断发展的维护的分析 确定：

• 用户、操作和培训手册方面的不足 • 不存在下列之间的服务水平协议： • 供应商和IT职能部门 • IT职能部门和用户

• 在开发和运行所需应用方面的组织的弱点

5.1 培训

5.5 数据转换

5.4 系统转换

5.3 实施计划

容量和吞吐量测量

达成一致的验收接受标准 信息规范 IT资源 P 效果 * 人员 效率 * 应用 保密 * 技术 S 完整 * 设施 S 可用 * 数据 遵从 可靠

5.6 测试策略和计划

5.2 应用软件的性能度量

作为每一个信息系统开发、执行和修改项目的一个部分，机构的系统开发生命周期方法应规定，按照一个预先建立好的计划，将来自老系统的必须元素转换到新系统上。

应由相关部门人员准备、检查和批准实施计划，并被用于测量实施进度。实施计划应针对实施场所的准备、设备的获取和安装、用户的培训、操作软件变更的安装、操作程序和转换的实施。

受到影响的用户部门及IT职能部门操作组的人员，应按照既定的培训计划和相关资料进行培训，这种培训应视为每一个信息系统开发、执行或修改项目的一部分。

应用软件的性能度量（最优化）应作为机构的系统开发生命周期方法的一个完整的组成部份而建立，以预测运行新的或已有重大变化的软件所需要的资源。

管理层应要求准备数据转换计划，定义被转换数据的收集和校验以及辨识和解决转换中出现错误的方法。应执行的测试包括：比较原始文件和转换后的文件；检查转换后的数据与新系统的兼容性；转换后，检查主文件，确保主文件数据的精确性；在最初转换到最后执行这段时间里，确保影响主文件的交易更新新旧两个系统的主文件。应对新系统的初始处理进行详细的校验，以确认其成功实施。管理层应确保数据成功转换的责任属于系统的所有者。

应准备测试策略和计划，并由系统所有者和IT管理层审定。

5.12 投入生产

5.11 操作测试

5.7 变更的测试

5.9 最终验收测试

5.10 安全测试和鉴定

5.14 管理的实施后评价

5.13 满足用户需求的评估

5.8 平行/穿行测试标准和实施

管理层应定义和执行一定的程序，确保操作和用户管理层，在接受系统剩余风险的同时，正式认可系统的测试结果和安全水平。这些程序应反映已经协商一致的最终用户、系统开发、网络管理和系统操作人员的角色和责任，同时需要考虑职责分离、监督和控制问题。

管理层应确保，在系统的变更用在正规的运行环境之前，在分开的测试环境中，按照影响和资源评估的角度，由（来自建造者）的测试小组进行测试。也应开发退回计划。验收测试应在一个代表未来运行环境的环境（例如，类似的安全、内部控制、负荷量等等）中进行。

管理层应定义和执行一个正式的程序，以控制系统从开发到测试再到运行的移交。在新系统被移交生产之前，管理层需要得到系统所有者的授权，并且，在旧的系统废止之前，新系统要成功运行整天、整月和整季的生产周期。新旧系统各自的环境应被分离而且要适当加以保护。

作为新的或者修改的信息系统的最终验收或质量保证测试的一部分，程序应规定，由受影响的用户部门和IT职能部门管理层对测试结果做正式的评估和批准。测试应覆盖信息系统的所有组成部分（例如，应用软件、设施、技术、用户程序）。

应建立程序，确保平行或穿行测试按照事先建立好的计划执行，而且终止测试过程的标准也要被事先详细说明。

机构的系统开发生命周期方法应要求投入运行的信息系统实施后的评价，评估并报告系统是否象预想的那样，以最大成本效率的方式，实现了收益。

机构的系统开发生命周期方法应要求，对投入运行的信息系统的需求（如，容量、吞吐量等）进行实施后的评价，以评估系统是否满足用户的需求。

管理层应确保在系统移交运行之前，用户或者指定的管理人（被指派而代表用户运行系统的当事人）将系统作为一个完整的产品，在与应用环境类似的条件下，以系统即将运行的生产环境的方式，验证它的运行。

评估控制：

获得了解：

评定遵从性：

对高级和详细的控制目标进行审计：

访谈：

首席信息官（CIO） IT管理层

IT培训、应用开发、安全、质量保证和操作管理 安全官

挑选的最近已经开发完成/正在开发系统的用户管理 与供应商为系统开发资源而签定的合同 获得：

相关于系统开发生命周期计划编制以及与下列相关的IT和程序的机构的和程序：安全和委员会；系统开发生命周期计划编制；程序的系统开发测试程序、单位、系统测试计划；用户的培训；系统从测试环境到生产环境的移植，质量保证和培训

系统开发生命周期计划和时间安排、系统开发生命周期编程标准，包括变更的申请过程 采样系统开发努力的状况报告 来自先前开发努力的实施后的报告

考虑是否：

与系统开发生命周期过程相关的和程序存在

系统安装和鉴定合格的正式的系统开发生命周期方法到位，包括但不限于此，下述分阶段的方法：培训、性能尺寸、转换计划、程序测试、程序（单位）和全部系统的小组、并行或原型测试计划、验收计划、安全测试和鉴定合格、操作测试、变化控制、实施和实施后评价以及修改

作为每一个开发努力一部分的用户培训正在发生

程序/系统控制与机构的安全标准、IT、程序和标准相一致 进行中的系统具有不同的开发、测试和生产库

测试成功、失败及更进一步努力的终结存在预先定义的标准

质量保证过程包括开发向生产库的移植、必需用户的完整性以及运行小组的验收 容量、处理间隔的模拟以及输出的可用性、安装和鉴定合格的测试计划是过程的一部分

与几个系统开发努力的例子相联系的培训程序包含：与先前系统的差异、影响输入的变化、登录、处理、时间安排、分发、与其它系统的接口、差错和差错的解决

自动化的工具使被开发的系统优化，一旦用在生产环境中，这些工具被用于效率机遇 与小于最优化性能相关的问题的解决正在发生

测试：

用户培训的正式计划已经被包括在所有新系统的开发努力中

职员意识到并理解正式的系统开发控制的需要以及每一个开发的安装和实施的用户培训

在系统设计、通过、测试、培训、转换和实施过程中，挑选的用户意识及对他们职责的理解众所周知并被公认

新的或者修改的系统的系统的实际成本与对应的估计成本以及实际的性能与对应的所希望的性能正

证实没有满足业务目标的风险：

在被追踪

覆盖信息系统资源所有领域的测试计划存在：应用软件、设施、技术和用户 用户理解系统开发过程中的所有阶段和职责，包括： • 设计说明书，包括开发周期期间的反复 • 成本/效益分析和可行性研究 • 系统开发过程的每一步骤的通过

• 测试计划以及计划发生后的测试结果的卷入和评估 • 穿过开发周期的系统的通过和验收 • 最终通过和系统的验收

• 为最近交付系统的充足性而接受到的培训的评估 开发人员和管理层确定曾经同意的用户需求的稳定性 比较供应商的交付物与相对的自己开发产品的用户满意度

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的系统安装和鉴定合格的基准 下述的详细评价：

• 满足用户满意度的最终期限和任务的开发小组——完成时，包括系统功能 • 与先前的系统相关的培训资料

• 质量保证职能部门的性评价以及从测试到生产状况和库移植的系统

• 被用来采集维护和优化统计数据，确保朝着以最小的成本得到最大的性能的所开发应用达到的支持的网络和资源监控工具

• 决定下述可用性开发努力的记录： • 用户的培训 • 安全

• 软件性能

• 测试文档和结果 • 转换计划

• 向生产环境的迁移 • 开发期间的变更控制 • 用户需求的满足 • 并行或穿行测试 • 实施后的评价

• 关于系统设计过程的内部或者外部审计的结论

• 确定结果满足预先定义的标准和系统所有功能的测试结果被包含在测试计划中 • 测试结果、任何终止的测试或开发项目的管理层讨论 • 开发过程的用户参与

• 有助于再造活动或按照所需要进行差错分析的审计痕迹 • 供应商参与的开发努力包括： • 成本的合理性 • 最终期限的满足 • 交付的功能性 确定：

对于最近的系统开发生命周期项目：

• 系统开发过程的每一个阶段的用户参与和正式通过 • 程序、单位、系统（包括并行或原型）、转换、实施以及实施后的评价的测试计划

6 管理变更（AI6）

6.1 变更请求的初始和控制

• 与安全和内部控制标准适当的一致 • 适当的数据转换任务和时间安排

• 测试的发生于系统的开发、修改或维护

• 由用户正式验收系统的功能、安全、完整以及残余风险

时间安排、运转、恢复/重新启动、备份/恢复以及差错解决的操作手册要选择： •生产库与开发或测试库在物理和逻辑上要分离

• 当用户期望和系统交付的功能之间发生冲突时解决的程序 对于供应商：

• 供应商的关系是正式的，并且存在合同 • 详细而明确的服务和成本被勾画出来

• 供应商的性能与机构的系统开发生命周期方法同等地控制 • 供应商已经满足了合同的性能、最终期限和明确的成本

控制的IT过程： 管理变更

满足的业务需求：

使中断、未经授权的变更和差错的可能性最小化 实现路线：

建立一套管理体系，规定被要求的所有变更的分析、执行和后续处理，并将其构筑到现有的IT基础设施之中

需要考虑的事项： 变更的识别

分类、排列优先顺序以及紧急事件程序 影响的评估 变更的授权

版本发布的管理 软件的分发

自动化工具的使用 配置管理

业务过程的重新设计 信息规范 IT资源 P 效果 * 人员 P 效率 * 应用 保密 * 技术 P 完整 * 设施 P 可用 * 数据 遵从 S 可靠

IT管理层应确保变更、系统维护和供货商维护的所有请求标准化，并要服从于正式的变更管理程序。变更应被分类和排列优先顺序，并应建立特殊的程序以处理紧急事件。变更的请求者应能够获悉其请求受理的状态。

获得了解：

6.4 紧急变更

6.8 软件的分发

6.6 授权的维护

6.5 文档和程序

6.3 变更的控制

6.2 影响的评估

6.7 软件发布

IT管理层应确保变更管理以及软件控制和分发与一个全面的配置管理系统适当地集成在一起。用于监控应用系统变更的系统应是自动化的，以支持巨大、复杂的信息系统产生的变更的记录和追踪。

应建立具体的内部控制措施，确保正确的软件要素被完整、及时地分发到正确的地方，并留下适当的审计痕迹。

IT管理层应建立定义紧急变更和程序的参数，以便实施前，当变更绕过技术、操作和管理评估的正常过程时，控制这些变更。紧急变更应被记录，并在执行之前由IT管理层授权。

应建立相应的程序，确保变更的所有请求，都能以结构化的方式，评估其对于运行的系统及其功能性的所有可能的影响。

IT管理层应确保维护人员有明确的分工，并且他们的工作要被适当地监控。另外，应控制他们的系统访问权限，以避免对自动化系统非授权访问所造成的风险。

访谈：

首席信息官（CIO） IT管理层

IT系统开发、变更控制质量保证、操作和安全管理层 涉及信息系统应用的设计和使用的挑选的用户管理层 获得：

变更过程应确保不管系统变更何时实施，其相关的文档和程序也要被相应地更新。

IT管理层应确保软件的发布由确保签署、打包、回归测试、移交等正式的程序所支配。

对高级和详细的控制目标进行审计：

评估控制：

评定遵从性：

与下述相关的机构的和程序：信息系统的计划编制、变更控制、安全和系统开发生命周期

与下述相关的IT和程序：正式的系统开发生命周期方法、安全标准、测试标准、的质量保证、实施、分发、维护、紧急情况变化、软件的发布和系统的版本控制

应用开发计划

变更控制申请的格式和日志

与应用开发服务相联系的供应商合同

测试：

下列变更的实例要由管理层通过： • 变更的申请 • 变更的说明书 • 源程序的访问 • 变更程序员完成

• 将源程序移入测试环境的申请 • 接受测试的完成

• 编辑和移入生产环境的申请

• 全面和具体的安全影响已经决定并接受 • 分发过程已经开发

下述变更控制文档内含物的评价： • 申请变更的数据 • 人的请求

• 变更申请的通过

• 制造的变更——IT职能部门的通过 • 制造的变更——用户的通过 • 文档更新日期 • 将数据移入生产 • 变更的质量保证签署 • 由操作的接受

分析系统趋势的确认的变更的类型

评估IT库的足够性，决定底线编码水平，以防止差错的衰退

考虑是否：

来自用户区分优先顺序的系统变更申请的方法存在并在使用 紧急情况变化程序在操作手册中被说明

变更控制对用户和开发组两者来讲都是正式的程序 变更控制日志确保展示出来的所有变化都被解决

用户对变更申请的突然好转——及时性和成本感到满意 关于变更控制日志中的变更的选择： • 导致程序和操作文档变化的变更 • 由于要制成文档而产生的变更 • 当前的文档反映变化的环境

变更过程正在监控在感谢、响应时间、响应效力以及用户对过程的满意度方面的进步 电话交换机（PBX）系统的维护包含在变更控制程序中

证实没有满足业务目标的风险：

编码变更的签到和签离程序存在

变更控制的日志确保日志上的所有变更被解决到用户满意的程度，没有变更就不会产生变更日志 用户要知道并理解正式变更控制程序的要求 人员的强制执行过程要确保遵从变更控制程序

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的变更控制管理的基准 对于挑选的信息服务功能系统：

• 决定申请或者系统变更的文档，这些文档已经由受影响的用户领域和服务提供商的管理层所通过并排出优先顺序

• 确定变更控制形式方面的影响评估的存在和适当

• 由提供变更申请收据的系统服务职能部门提供的通知 • 适当开发资源变更的分配

• 系统和用户测试计划及结果的适当性

• 通过质量保证小组，从测试到生产的正式的迁移 • 反映变更的最新的用户和操作手册 • 分发给适当用户的新的版本 确定：

对于选择的信息变更： • 仅仅是通过的变更才做 • 所有的变更被说明

• 当前的库（源和目标）反映最近的变更

• 变更控制程序的差异被记录并在说明下列之间的关系： • 购买和自己开发的应用 • 应用和系统软件

• 变更控制的供应商对待

1.1 服务水平协议框架

1.2 服务水平协议的样式

1 定义和管理服务水平（DS1）

交付和支持

控制的IT过程： 定义和管理服务水平 满足的业务需求：

建立对所需服务水平的共同理解 实现路线：

使绩效标准正式化的服务水平协议的确立，依照该协议衡量服务的数量和质量 需要考虑的事项： 正式的协议 责任的定义

响应时间和数量 收费

完整性保证 非披露协议

客户满意度标准

所要求服务水平的成本/效益分析 监控与报告 信息规范 IT资源 P 效果 * 人员 P 效率 * 应用 S 保密 * 技术 S 完整 * 设施 S 可用 * 数据 S 遵从 S 可靠

清楚的协议应达到一种服务水平协议应具有的样子，服务水平协议应至少包括以下方面的内容：可用性、可靠性、性能、成长能力、提供给用户的支持水平、持续性计划编制、安全、交付的系统功能最小可接受的满意水平、（在工作量上的）、服务的收费、中心打印设施（可能）、中心打印件分发和更改程序。

管理层应定义一个框架，框架中，要促进正式服务水平协议的定义的开发，定义最小限度的内容：可用性、可靠性、性能、成长能力、提供给用户的支持水平、持续性计划、安全、交付系统功能最小可接受的满意水平、（在工作量上的）、服务收费、中心打印设施（可能）、中心打印件分发和更改程序。用户和IT职能部门应有一个书面的协议，用于定量和定性描述服务水平。这个协议定义了双方的责任，IT职能部门必须提供约定的服务质量和数量，用户必须约束其需求在认可的限度内。

获得了解：

1.6 收费条款

1.3 执行程序

1.4 监控与报告

1.7 服务改进程序

1.5 服务水平协议和合同的评价

为了追求服务水平合理成本的不断改进，管理层应执行一个过程，保证用户和服务水平管理者有规律地同意服务改进程序。

收费条款的规定应包括在服务水平协议中，以便相对与成本来讲，使服务水平方面的公平交易成为可能。

应有一个程序，以确保履行管理所有各方关系（如，非披露协议）的方式和责任被建立、协调、维持，并能够与所有影响到的部门进行沟通。

管理层应任命一个服务水平的管理者，由他来负责监测和报告特定的服务执行标准的达到程度以及处理过程中所遭遇的所有问题。监测统计数据应被及时分析，适当的纠正行动应被执行，失败应被调查。

访谈：

首席信息官（CIO） IT高级管理层

IT合同/服务水平管理人 IT操作管理层 用户管理层 获得：

与提供者/用户关系相关的机构范围内的和程序 与下述相关的IT和程序： • 服务水平协议

• 操作报告内容、时间选择和分发 • 性能追踪方法 • 纠正行动活动

与下述相关的IT文档： • 服务水平性能报告

对于服务水平协议和在此基础下的第三方服务提供者合同，管理层应实施定期的评价程序。

对高级和详细的控制目标进行审计：

评估控制：

评定遵从性：

• 返款算法和计算费用的方法 • 服务改进程序

• 由非性能产生的追索权

• 与内部和外部用户以及服务的提供商签定的服务水平协议

测试：

对于过去和正在进行的服务水平协议的实例来讲，内容包括： • 服务的定义 • 服务的成本

• 可以计量的最小的服务水平 • 来自IT职能部门的支持水平 • 可用性、可靠性、成长的能力 • 协议的任何部分的变更程序 • 持续性计划 • 安全需求

• 服务的提供者和用户之间的书面和正式通过的协议 • 有效期和新的期间的评价/更新/非更新 • 性能报告的内容和频率以及服务的付款

• 与历史、行业、最好的实践相比较，费用是现实的 • 费用的计算

考虑是否：

服务水平协议过程由所确定

对创造和修改协议来讲，要求用户参与这一过程 用户和提供者的责任被定义

管理层要监控并报告有关详细的服务性能标准的实现以及遭遇到的所有问题 由管理层执行的有规律的评价过程存在 非性能的追索权过程被确定

服务水平协议包括，但并不限于此： • 服务的定义 • 服务的成本

• 可以计量的最小的服务水平 • 来自IT职能部门的支持水平 • 可用性、可靠性、成长的能力 • 持续性计划 • 安全需求

• 协议的任何部分的变更程序

• 服务的提供者和用户之间的书面和正式通过的协议 • 有效期和新的期间的评价/更新/非更新 • 性能报告的内容和频率以及服务的付款

• 与历史、行业、最好的实践相比较，费用是现实的 • 费用的计算

• 服务改进委托事项

证实没有满足业务目标的风险：

2 管理第三方服务（DS2）

• 服务改进委托事项

• 用户和提供者两者的正式通过

适当的用户知道并理解服务水平协议过程和程序

对当前服务水平过程和实际的协议的用户满意水平是充分的 服务提供确定非性能原因的记录，确保性能改进的程序到位 实际收费的准确性要与协议的内容相匹配

依照先前的服务改进委托事项而进行的历史性能被追踪

特定服务性能实现的报告由管理层适当地使用，确保满意的性能 遭遇到的所有问题的报告由管理层适当地使用，确保采取纠正行动

控制的IT过程： 管理第三方服务 满足的业务需求：

确保第三方的角色和责任得到清晰地定义、遵循并持续地满足业务的需求 实现路线：

着眼于现有协议和程序的有效性，以及遵从机构的评价和监控的控制措施 需要考虑的事项： 第三方的服务协议 合同管理 非披露协议

法律和法规的要求 服务交付的监控与报告 企业和IT风险的评估 绩效的奖惩

内部与外部机构的问责制 成本和服务水平差异的分析 信息规范 IT资源 P 效果 * 人员 P 效率 * 应用 S 保密 * 技术

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的服务水平协议的基准 评价下述：

• 决定使义务有效的定性和定量规定的服务水平协议被定义并被满足

• 挑选的确定问题解决程序，特别是非性能的服务水平协议被包括并被满足 确定：

描述、协调和沟通信息服务的提供者和用户之间关系的规定的适当性 被选择信息种类的不正确考虑

由服务水平报告的管理层正在进行的评价和纠正行动 与成本/效益分析相比较，被提议的服务改进的适当性 满足将来改进委托事项的提供者能力的适当性

S 完整 S 可用 S 遵从 S 可靠

2.8 监控

2.7 安全关系

2.5 外包合同

2.3 第三方合同

2.2 所有者关系

2.1 供应商接口

2.6 服务的连续性

2.4 第三方的资格认证

* 设施 * 数据

在选择之前，管理层应通过对提供所需服务能力的评估（应有的勤奋），来认证潜在第三方适当的资格。

关于与第三方服务提供商的关系，管理层应确保安全协议（如非披露协议）被确定、明确地陈述并一致通过，按照法律和规章的要求，包括义务，安全协议要遵从通用的业务标准。

应定义一个专门的机构程序，确保设施管理提供者和机构之间的合同，是基于所要求的处理水平、安全、监控和意外事故需求以及其它适当的约束的。

管理层应定义详细的程序，对于每一个与第三方服务提供者关系来讲，确保在工作开始实施之前，先要与之定义正式的合同并达成一致。

为了确保服务的连续性，根据法律的不确定性和持续经营的概念，管理层应考虑与第三方相关的业务风险，合适时，要磋商有条件的契约合同。

管理层应确保所有第三方供应商的服务被适当确认，而且，与供应商的技术和机构上的界面应备有档案。

第三方服务交付的监控程序应由管理层建立，确保持续遵守合同协议。

客户机构的管理层应任命一个关系所有者，负责确保与第三方关系的质量。

评估控制：

获得了解：

对高级和详细的控制目标进行审计：

访谈：

首席信息官（CIO） IT高级管理层

IT合同/服务水平管理人 IT操作管理层 安全官 获得：

与购买的服务，特别是第三方供应商关系相关的机构范围内的社程序

与下述相关的IT和程序：第三方关系、供应商的选择程序、这种关系的合同内容、物理和逻辑的安全、供应商的质量维护、意外事故计划和外包

所有当前第三方关系的清单和与每一个第三方相联系的实际合同 与第三方关系和服务相联系的服务水平报告

讨论合同评价、性能评估和关系管理的会议的纪要 所有第三方关系的秘密协议

对供应商是可能的的特性文件和资源的安全访问清单

考虑是否：

与第三方关系相联系的IT和程序存在，并与机构的总体一致

特别说明合同的要求、合同内容的定义、所有者或关系经理确保合同按要求被创造、维护、监控和重新谈判的存在

参与项目行为的代理和任何其它当事人，如转包商的接口的定义 合同描绘全面和完整的第三方供应商关系的记录 合同特别地为服务的持续性而建立，这些合同包括由供应商确保用户服务的持续性服务所进行的意外事故计划

合同内容起码包括以下： • 正式的管理和法律的通过 • 提供服务的法人实体 • 所提供的服务

• 定性和定量的服务水平协议

• 服务的成本以及支付服务款项的频率 • 问题过程的解决 • 非性能的处罚 • 分解过程 • 修改过程

• 服务的报告——内容、频率和分发 • 合同生命期间合同当事人之间的角色 • 服务将由供应商提供的持续性保证

• 服务的用户和供应商沟通的过程和频率 • 合同的期间

评定遵从性：

• 提供给供应商的访问水平 • 安全需求 • 非披露保证

• 访问权利和审计权利

如果适用的话，由第三者保存附带条件委付盖印的协议已经被商议 通过释放所需服务能力的评估（应有的勤奋），潜在的第三方当事人具有适当的资格

测试：

合同清单、到位的实际合同是准确的 没有在合同清单中的供应商不提供服务

在合同中的供应商实际上正在执行所定义的服务 供应商管理层/所有者理解合同中的责任

与第三方关系相关的IT和程序存在，并与机构的总体想一致

明确地说明合同的需要、合同内容的定义、所有者或关系经理按所需确保合同被创造、维护、监控和重新谈判的责任的存在

合同描绘了全面和完整的第三方供应商关系的记录 特别为服务的持续性建立合同，这些合同包括由供应商确保服务用户的持续性服务的意外事故的计划 合同内容起码包括以下： • 正式的管理和法律的通过 • 提供服务的法人实体 • 所提供的服务

• 定性和定量的服务水平协议

• 服务的成本以及支付服务款项的频率 • 问题过程的解决 • 非性能的处罚 • 分解过程 • 修改过程

• 服务的报告——内容、频率和分发 • 合同生命期间合同当事人之间的角色 • 服务将由供应商提供的持续性保证

• 服务的用户和供应商沟通的过程和频率 • 合同的期间

• 提供给供应商的访问水平 • 安全需求 • 非披露保证

• 访问权利和审计权利

用户知道并理解合同的要求以及提供服务的合同 卖主和机构之间的适当的性存在 卖主来源和选择过程的性正在发生

安全访问列表仅仅包括所需的最小数量的卖主人员，并且访问是所要求的最小的 机构资源的硬件和软件访问被管理和控制到最小化的卖主使用 正在执行的服务的实际水平与较高的契约义务相比较

外包的设施、人员、操作和控制确保比得上期望的所需的性能水平 由第三方当事人所进行的服务交付的持续监控由管理层所执行 承包者操作的审计发生

证实没有满足业务目标的风险：

3 管理性能和容量（DS3）

潜在第三方当事人评估他们释放所需服务能力的评估报告存在 诉讼活动的历史——过去和当前

涉及项目管理的代理的接口要在合同中制成文档 要覆盖与程控交换机（PBX）供应商的合同

控制的IT过程： 管理性能和容量 满足的业务需求：

确保足够的容量可用，而且能够最好、最优化地使用，以满足所要求的性能需求 实现路线：

资源性能、应用规模和工作量需求方面的数据收集、分析和报告 需要考虑的事项： 可用性和性能需求 自动的监控和报告 模型工具 容量管理 资源的可用性

硬件和软件的性能/价格比变化 信息规范 IT资源 P 效果 人员 P 效率 * 应用 保密 * 技术 完整 * 设施 S 可用 数据 遵从 可靠

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的第三方服务的基准 决定确定义务的定性和定量的规定的每一个第三方合同的详细评价被定义 确定：

规定的描述、信息服务的提供者和用户之间的协调和沟通 第三方的精确地反映所选择合同服务的费用

与第三方卖主的机构联络确保服务的当事人和用户之间合同问题的沟通 法律律师和管理层通过所有的合同

正在进行的风险评估发生，以确定关系的要求或者修改关系的要求 由合同报告的管理层正在进行的评价和纠正行动正在发生

比较不同的内部、外部和行业可比较的性能的费用的合理性被做

对于所有的契约服务来讲，意外事故计划到位，特别是IT职能部门的灾难恢复服务 对于外包的职能来讲，明显的缺点或改进性能的机会或减少成本存在 包含在承包者的审计中的建议的实施正在发生

3.4 模型化工具

3.3 监控和报告

3.2 可用性计划

3.8 资源的可用性

3.9 资源的时间安排

3.7 资源的容量管理

3.6 工作负荷的预测

3.5 前移的性能管理

3.1 可用性和性能需求

管理层应确保可用性计划的建立，以达到、监测并控制信息服务的可用性。

管理层应实施一个程序，确保持续地监控IT资源的性能，例外事件能得到及时和全面的报告。

管理程序应确保有关信息服务的可用性和性能业务需求的确认，并转换成为可用性条款和需求。

应设置适当的控制，确保工作负荷的预测准备到位，以确认趋势，并为容量计划提供所需的信息。

当确定可用性需求的时候，由于执行了容错机制、将任务区分出优先顺序以及平衡资源分配机制，管理层应防止资源难以获得的情况发生。

对于硬件性能和容量的评价来说，IT管理层应建立一个计划编制的过程，确保合理成本的容量总是存在，以处理已经协商过的工作负荷，并提供服务水平协议上规定的所需性能质量和数量。容量计划应包括多个情况。

性能管理的程序应包括预测容量，使问题在影响系统性能之前就能够被纠正过来。对于系统失败和频繁无规律的事件、影响的程度和毁坏的数量，应加以分析。

IT管理层应确保运用适当的模型化工具产生一个当前系统的模型，这一模型对照实际的工作负荷进行了校准和调整，在推荐的负载水平下是准确的。模型化工具应被用于容量、配置的可靠性、性能和可用性要求的辅助预测。应引导对系统的硬件进行深入的技术调查，应包括未来技术的预测。

管理层应确保及时地获取所需的容量，要考虑诸如弹性、偶然性、工作负荷和存储计划方面的问题。

评估控制：

获得了解：

评定遵从性：

对高级和详细的控制目标进行审计：

考虑是否：

由IT职能部门所提供的所有服务都定义了时间框架和服务水平 时间框架和服务水平反映了用户的需求

时间框架和服务水平与设备的潜在的性能预期相一致 可用性计划存在，是最新的并反映用户需求

正在进行的所有设备和容量的性能监控正在发生、向上报告，性能的缺乏由管理层说明，性能改进的机遇被正式说明

由模型工具监控最佳的配置性能，以便在最小化所需水平的容量的同时，最大化性能 用户和操作性能小组两者都要积极地评价容量、性能和工作负载，时间安排修改正在发生 工作负载预测包括来自用户变化需求以及来自供应商在新技术或当前产品改进上的输入

访谈：

IT高级管理层 IT操作管理层 IT容量管理层 IT网络管理层 获得：

与可用性、性能的监控和报告、工作负载的预测、容量管理以及时间安排相关的机构范围内的和程序

与以下相关的IT和程序：连接组织服务的可用性的业务计划的容量、可用性的计划编制、持续地监控和性能管理

关于容量和性能规范的卖主产品的表示法

硬件、软件、通信和外围设备的所有当前卖主产品的清单 通信网络监控报告

讨论容量计划、性能期望以及性能的“优良调整”的会议的纪要 可用性、容量、工作负载和资源的计划编制文档 包括容量和性能假设的年度IT预算

与IT职能部门内操作性能相关的报告，包括问题报告和解决的历史

测试：

性能、容量、可用性报告方面的统计是精确的，包括历史和与预测性能的不一致的解释 修改可用性、容量、工作负载计划文档的变更过程反映正在变化的技术或用户需求 工作流程分析报告说明额外处理效率的机遇

与用法和可用性相关的用户的性能报告信息存在，包括容量、工作负载时间安排和趋势 逐步升级的程序存在，被追随，在解决问题方面是适当的

系统开发方法执行后阶段包括决定将来成长和性能预期变化的标准 由IT职能部门提供的支持水平对支持组织的目的是足够的

4.1 IT持续性框架

证实没有满足业务目标的风险：

4 确保持续的服务（DS4）

控制的IT过程： 确保持续的服务 满足的业务需求：

确信IT服务象所要求的那样是可用的，确保重大的中断事件所产生的业务冲击最小 实现路线：

具有一套能使用并已经测试过的符合整体业务持续性计划及相关业务需求的IT持续性计划 需要考虑的事项： 危险程度分类 可选择程序 备份和恢复

系统和有规律的测试及培训 监控和逐步升级过程 内部和外部机构的责任

业务持续性的激活、回退和恢复计划 风险管理活动 单点失败的评估 问题管理 信息规范 IT资源 P 效果 * 人员 S 效率 * 应用 保密 * 技术 完整 * 设施 P 可用 * 数据 遵从 可靠

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的性能和容量管理的基准 正在进行的业务需求的测试，确保IT可用性条款和需求充分地反映这些要求

容量和资源计划过程评价，确保建立在变化着的业务需求基础之上的计划的及时修改 与容量、响应和可用性相关的性能预期正被满足的确认

来自成本/效益分析远景的性能需求的比较，确保容量或资源不过剩的存在 由管理层定期地产生并评价性能报告的确认 确定：

改进机遇或弱点补救的性能报告

用户和确认的性能预期被满足，以变化着的需求为基础的修改在计划中被反映

在处理期间确认问题发生的问题日志或报告以及时的方式被说明，并采取适当的纠正行动 遭遇的具体问题，确定问题解决过程的效果

IT管理层应与业务过程的所有者协调，建立一个持续性框架，在框架中，定义角色、责任和所采用的

4.6 测试IT持续性计划

4.5 维护IT持续性计划

4.8 IT持续性计划的分发

4.7 IT持续性计划的培训

4.3 IT持续性计划的内容

4.4 最小化IT持续性需求

4.2 IT持续性计划的策略与哲理

基于风险的途径/方法以及规则和结构，以便持续性计划的归档及其审批程序。

IT管理层应确保开发书面的计划，包含以下内容： 怎样使用持续性计划的指南

确保所有受影响职员安全的应急程序

响应程序：将业务带回到事件或灾难发生前的状态 恢复程序：将业务带回到事件或灾难发生前的状态 保护和再建场所的程序

与管理当局的协调配合程序

与以下人员的沟通程序：利害关系人、雇员、关键客户、关键的供应商、股东和管理层 有关持续性小组、受到影响的职员、客户、供应商、管理当局和媒体的关键信息

IT管理层应规定变更控制程序，以确保更新持续性计划，并反映实际的业务需求。这要求持续性计划维护程序要与变更、管理和人力资源程序联合起来。

管理层应确保IT持续性计划与总体的业务持续性计划保持一致，以确保连贯性。进一步，IT持续性计划应考虑到IT的长期和短期计划，以保持连贯性。

灾难连续性方法应确保所有相关各方人员定期受到关于紧急事件或灾难时的处理程序的培训。

设定持续性计划中信息的敏感性种类，然后应只将其分发给经过授权的人员，并应防止未经授权的披露。因此，该计划章节的分发应以“需要才能知道”为基础。

为最小化持续性需求，针对人员、设施、硬件、软件、设备、制度、供给和家具等方面，IT管理层应建立一个程序和指南。

为了具有一个高效的持续性计划，管理层需要定期或者当业务或IT基础设施发生重大变化时评估其适当性；这要求精心的准备、存档、报告测试结果，并依照结果，执行行动计划。

获得了解：

4.13 总结程序

4.12 远程备份存储

4.10 关键的IT资源

4.11 备份场所和硬件

4.9 用户部门的可选择处理备份程序

对高级和详细的控制目标进行审计：

持续性计划应确定出关键的应用程序、第三方服务、操作系统、人员和供给，数据文件和需要在灾难发生后恢复的时间段。关键的数据和操作应被确认、归档、区分优先顺序并在与IT管理层协商后，由业务过程所有者审批。

在灾难发生后IT功能的成功恢复方面，IT管理层应建立一个程序，评估计划的适当性并相应地更新计划。

管理层应确保持续性方法编入了有关的备份场所和硬件选择的确认，同样应编入最终的选择。如果适合，应签定一个正式的这些服务类型的合同。

持续性方法应确保用户部门建立一个可选择的处理程序，这个程序可以一直使用，直到灾难或事件后IT功能全部重新恢复对业务的支持为止。

应建立关键的备份媒介、文档和其它IT资源的远程备份，以支持恢复和业务持续性计划。业务过程所有者和IT职能部门的人员应参与决定哪些备份资源需要在远程存储。远程存储设施应在环境上适合于媒介和其它被存储的资源，而且应有保护备份资源不受未授权访问、偷盗或毁坏相称的安全级别。IT管理层应确保远程存储的安排在内容、环境保护和安全方面被定期地评估，至少一年一次。

访谈：

IT高级管理层 IT操作管理层 IT持续性管理层

人力资源或培训管理层 有持续性需求的用户组织 卖主恢复场所经理 非现场存储经理 风险和保险经理 获得：

与持续性计划编制过程相关的机构范围内的和程序

评估控制：

考虑是否：

机构的要求IT职能部门和所有依赖IT资源机构两者的持续性框架和计划作为标准操作需求的一部分

IT和程序要求：

• 与持续性计划开发的发展相关的一致的理念和框架 • 关于恢复和返回及时性的应用的优先顺序

• 风险的评估以及在IT功能和用户资源持续情形下考虑业务丢失的保险 • 用特定的测试、维护和更新需求，勾画持续性计划特定的角色和责任

• 与卖主签定的正式的合同安排，以便先于实际的要求，在需要恢复事件发生时，包括备份场所设施或关系，提供服务

• 每一个持续性计划包括的最小内容：

• 确保所有受影响的人员安全的紧急情况程序

• IT职能部门、提供恢复服务的卖主、服务的用户以及支持管理人员的角色和责任 • 与持续性的长期计划相一致的恢复框架

• 需要选择的系统资源（硬件、外围设备、软件）的清单

• 从最高到最低的应用优先顺序的清单、所要求的恢复时间和预期的性能标准

• 在需要恢复的事件发生时，在沟通和提供支持服务方面的管理职能，诸如，好处、薪水、外部通信、成本跟踪，等等

• 各种不同的恢复情节，从整个容量和响应损失的辅修，到每一个足够详细的一步步的执行

• 特定设备和供给需求被确定，诸如，高速打印机、签名、表格、通信设备、电话，等等，以及来源和可选择来源的定义

• 在持续性计划中个人和小组角色的培训和意识

• 建立在先前测试基础上的测试时间安排、最后测试的结果以及纠正行动被采取 • 已签定合同的服务提供者、服务和响应的预期要逐条记录

• 有关关键资源的场所方面的后勤信息，包括恢复运行系统的备份场所、应用、数据文件、操作手册以及程序/系统/用户文档

• 关键人员当前的姓名、住址、电话/寻呼机号码

• 在所有系统资源的原始位置重新恢复的重建计划被包括

• 一旦IT资源允许，对所有用户建立可选择工作场所的业务恢复选择；也就是说，除非用户的建筑物彻底地烧了，不可能使用，系统可以在可选择的地方恢复

关于持续性计划受规章制度影响的代理需求要满足

用户的持续性计划以为了执行关键的处理所需物理资源不可能使用为基础而开发——手工和计算机化

电话系统、声音邮件、传真和图象系统是持续性计划的一部分

图象系统、传真系统、纸文档与缩微胶片和大容量存储媒介一样是持续性计划的一部分

与下述相关的IT和程序：持续性框架、计划、理念、战略、应用的优先顺序、计划的测试、定期的备份、轮换和培训

IT持续性计划

持续性计划服务的用户

持续和业务恢复用户计划的最近的测试结果

在需要恢复的事件发生时决定应用优先顺序的方法 支持持续性支持服务的卖主合同 业务中断的保险

评定遵从性：

证实没有满足业务目标的风险：

测试：

持续性计划存在，是最新的，并被所有受影响的当事人所理解 定期的持续性计划的培训已经提供给所有涉及的当事人 关于计划开发的所有和程序已经被跟随

计划的内容是建立在上述描述内容的基础上的，包括： • 持续性计划目标已经被满足

• 适当的人已经被选择提供领导层的角色 • 计划已经收到了适当的评价并由管理层通过

• 计划最近已经被测试，并按照计划工作，所确定的任何差异导致计划的纠正 • 机构的持续性计划和业务计划之间的连接

• 可选择的手工程序被制成文档，并作为整体测试的一部分

用户和IT人员有关计划之内具体的角色、任务和责任的培训和意识已经发生 已经签定合同的卖主关系和交付时间与用户的期望和需要相一致 关于标准的非现场轮换程序，备份场所的内容是最新的和足够的 关键数据和操作被确定、制成文档并排出优先顺序 高级管理层通过关键数据和操作

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的持续性计划的基准 下述的详细评价：

• 确保适当战略及与整体业务持续性战略接口的计划目标

• 关于提供领导层作为计划的协调者方面，适当的责任的个人理解 • 由适当层次的高级管理层评价并通过的计划

• 被挑选的IT职能部门和用户部门的人员，以确定业务需求包含在持续性的计划当中

• 当需要发生时，可选择的手工数据处理用户程序，确保它们由使用的用户部门制成文档，直到事件后能够恢复处理操作为止

• 特定应用的供给，确保非现场位置上有足够的存货（也就是说，磁带、检查托盘、托盘证明，等等） 确定：

检验交付时间的卖主合同，以获得有关服务、时间、服务水平和成本的详细的供给和足量 获得专门的电讯或网络组件的供应

作为从短期到永久损耗的计划的一部分的多样化的情节 与用户的期望相一致的发生的应用优先顺序 具有与需求相称的非现场计算机设施的书面合同

可选择的场所处理速度、响应、可用性、支持作为足够的用户需求 在需要恢复时，确保他们持续性服务的卖主持续性计划

可选择的远离自己场所的可选择的服务提供商，消除相互恢复事件的可能 已经发生计划的定期测试，在测试基础上的计划调整

IT和用户人员两者都要有规律地接受持续性计划方面的培训

具有来自原场所的可选择处理移植处理的类似的重建队伍、任务和责任以及测试

5.1 管理安全措施

5.2 确认、授权和访问

5 确保系统安全（DS5）

控制的IT过程： 确保系统安全 满足的业务需求：

保护信息不被非授权使用、披露或修改、毁坏或丢失 实现路线：

确保对系统、数据和程序访问的逻辑访问控制被在授权用户内 需要考虑的事项： 保密和隐私要求

授权、鉴别和访问控制

用户识别和授权特征描述文件 需要才能有和需要才能知道原则 密钥管理

突发事件的处理、报告和跟踪 病毒预防与检测 防火墙

集中的安全管理 用户培训

用于监控遵从性、入侵测试和报告的工具 信息规范 IT资源 效果 * 人员 效率 * 应用 P 保密 * 技术 P 完整 * 设施 S 可用 * 数据 S 遵从 S 可靠

应对IT安全进行管理，这样的安全措施标准要与业务需求一致。包括： 将风险评估信息传递到IT安全计划中 实施IT安全计划

更新IT安全计划，以反映IT配置的变化 评估IT安全方面的变更请求的影响 监控IT安全计划的执行

IT安全程序与其它和程序的协调一致

逻辑访问和IT计算资源的使用应由适当的识别、鉴别、授权的机制所，用访问规则连接用户和资源。这样的机制应能防止未经授权的人员、电话拨号连接和其它系统（网络）入口访问计算机资源，并使授权用户多个登录的要求最小化。也应有一个程序，保持鉴别和访问机制有效性（例如有规律的密码更改）。

5.8 数据分类

5.7 安全监督

5.4 用户帐户的管理

5.6 用户帐户的用户控制

5.5 用户帐户的管理评价

5.3 联机访问数据的安全

5.10 侵犯和安全活动报告

5.9 中心确认和访问权限管理

用户应系统性地控制他们的适当帐户的活动。也应建立信息机制，既要允许用户检查正常的活动，也要以及时的方式对非正常的活动进行报警。

管理层应有一个控制程序，定期评价和确认访问权限。定期地将资源使用与记录的责任进行比较，有助于减少错误、欺骗、误用和未经授权变更的风险。

在联机IT环境中，IT管理层应执行与安全保持一致的程序，该安全提供基于个体的已经论证需求的安全控制，以查看、添加、更改或删除数据。

应设置一个控制，确保用户身份识别和访问权限以及系统的身份和数据的拥有权以唯一和中心管理的方式被建立和管理，以此来获得全局访问控制的一致性和有效性。

IT安全管理员应确保安全活动被记入日志，任何即将来临的安全侵犯的迹象要立即报告给所有相关内部、外部人员，并及时采取行动。

管理层应执行一个程序，确保所有的数据，按照数据分类的计划安排，由数据的所有者通过正式和明确的决策，根据敏感性进行分类。即使数据“不需要保护”，也需要一个正式决策以指明这样设计的理由。所有者应决定数据的布置与共享，也就是是否、何时进行程序和文件的维护、存档或删除。所有者批准和数据布置的证据应被维护。应被定义，以基于变化的敏感性，支持信息的重新分类。分类方案应包括管理机构之间信息交换的规范，要注意安全以及对有关法律的遵从性。

IT安全管理员应确保侵犯和安全活动被记入日志、报告、评价有规律地适时逐步升级，以便确认和解决有关未授权活动。对计算机资源责任信息的逻辑访问（安全和其它日志文件）应基于最小或者“需

管理层应建立一个程序，确保相关用户帐户的申请、建立、发放、暂停和关闭的及时进行。应包括一个概述数据或者系统所有者准予访问的正式批准程序。第三方访问的安全应以合同形式被定义，要专注于管理和非披露要求。在各方之间的合同中，外包安排应专注于信息系统和网络的风险、安全控制和程序。

要才能知道”的原则来准予。

5.18 密钥管理

5.15 不可否认

5.14 交易授权

5.12 重新鉴定

5.11 事件处理

5.16 可信任的路径

5.13 交易对手信任

5.17 安全功能的保护

机构应确保敏感交易数据只能通过可信任的路径来交换。敏感信息包括：安全管理信息、敏感交易数据、口令和密钥。为了实现这些，可信任的通道需要使用用户之间、用户和系统之间、系统和系统之间的加密来建立。

机构应确保在合适的地方，交易不能被任何一方拒绝，并且执行控制，以提供发起或接收方提交的证据和交易的收据的不可否认性。通过数字签名、时间戳记和可信任的第三方，考虑了相关制度要求的适当，实现这一程序。

机构的应确保在合适的地方执行控制，以提供交易的授权，并建立用户自己对系统声称的身份校验。这要求使用密码技术进行签字和校验交易。

机构的应确保执行控制实践，以检验核实提供电子指令或交易的交易对手的真实性，这些可以通过密码、标识或密钥的可信任交换来实现。

总是应防止所有涉及硬件和软件安全的损害，以维持它们的完整性，并要防止密钥的泄露。另外，机构应对他们的安全设计保持一种低调的形象，但是安全不能基于对设计的保密。

管理层应建立计算机安全事件处理能力，通过提供足够的专家意见和装备有迅速而安全的通讯设施的集中化平台，来处理安全事件。应建立事件管理的责任和程序，确保对安全事件适当、有效和及时的响应。

管理层应确保定期地执行安全的重新鉴定（例如，通过“tiger teams”），以保持正式更新已经批准的安全级别和剩余风险的容忍度。

管理层应定义并执行程序和协议，用于密钥的生成、更改、撤消、毁坏、分发、认证、存储、输入、使用和存档，确保密钥不被更改和未经授权的泄露。如果一个密钥危及安全，管理层应确保这个信息，

获得了解：

5.21 电子化价值的保护

5.19 恶意软件的预防、检测和纠正

5.20 防火墙体系以及与公共网络的连接

通过认证撤消列表或其它类似的机制，传播到所有感兴趣的伙伴那里。

管理层应保护用于身份鉴别或财务存储或储存其它敏感信息的所有卡片或者类似物理装置的持续完整性，应考虑相关设施、装置、雇员和使用的验证方法。

关于恶意软件，诸如计算机病毒或者特洛依木马，管理层应建立一个适当的预防、检测和纠正控制措施以及出现时的响应和报告的框架。业务和IT管理层应确保建立一个跨越全机构的程序，避免信息系统和技术遭受计算机病毒的侵害。程序应结合病毒预防、检测、发生时的响应和报告。

如果存在与因特网或其它公共网络的连接，则应发挥适当的防火墙的作用，以防止服务拒绝和对内部资源的任何未经授权的访问；应在两个方向控制任何应用和基础设施管理流，应防止服务拒绝的攻击。

对高级和详细的控制目标进行审计：

访谈：

机构的高级安全官 IT高级和安全管理层 IT数据库管理人 IT安全管理人 IT应用开发管理层 获得：

与信息系统安全和访问相关的机构范围内的和程序 与信息系统安全和访问相关的IT和程序 相关的和程序、法律和规章团体的信息系统安全需求（也就是说，法律、规章、指南、行业标准），包括：

• 用户帐号管理程序

• 用户安全和信息保护 • 有关电子商务的标准 • 数据分类大纲

• 访问控制软件的清单

• 住房供给IT资源的建筑物/房间的楼层计划

• IT资源（也就是说，调治解调器、电话线和远程终端）物理访问点的清段和示意图 • 安全软件变更控制过程

• 问题追踪、解决和逐步升级的程序 • 安全违背的报告和管理评价的程序 • 数据加密设备和加密标准的清单

评估控制：

• 访问系统资源的卖主和客户的清单 • 用在数据传输的服务提供者的清单 • 关于持续的安全测试的网络管理实务 • 与数据传输服务提供者合同的拷贝

• 签字盖章的用户安全和认识文档的拷贝 • 与安全相关的新雇员培训资料的内容

• 来自外部审计、第三方服务提供者和中介的与信息系统安全相关的审计报告

考虑是否：

提供集中的方向、控制信息系统安全，连同一致性的用户安全需求的战略安全计划到位 负责确保仅仅适当地访问系统资源的集中的安全机构到位

数据分类大纲到位并正在被使用，所有的系统资源都有一个所有者负责其安全和内容

描绘“最小访问要求”的用户安全特性文件到位，该特性文件有规律地由重新鉴定的管理层评价 雇员的教导包括安全意识、所有者的责任以及病毒保护的需求 安全违背的报告存在，正式的问题解决程序到位，这些报告包括： • 未授权的访问系统的企图（签约） • 未授权的访问系统资源的企图

• 未授权的查看或更改安全定义和规则的企图 • 由用户ID特许的资源访问

• 授权的安全定义和规则的变更

• 授权的资源访问（选择用户或资源） • 系统安全状况的变更

• 操作系统安全参数表的访问

密码模数和密钥维护程序存在，集中地管理，用于所有外部访问和传输活动 集中的和用户行为的两者的密码密钥管理标准存在

安全软件的变更控制是正式的，与系统开发和维护的正规标准相一致 使用中的证明机制提供一个或者更多的下列特征：

• 证明数据的专一使用（也就是说，口令永远不能是再度使用的） • 多重证明（也就是说，两个或两个以上不同的证明机制被使用）

• 基于证明的（也就是说，为具体的事件指定单独的证明程序的能力） • 按需要求的证明（也就是说，初始证明之后，不时重新证明用户的能力） 属于同一用户的并发会话的数量被

登录时，一个劝告的关于适当地使用硬件、软件或连接的用户警告信息登录 先于完成登录，一个警告屏幕被显示，以告知读者未授权访问可能导致的起诉 成功的会话建立之后，要为用户显示访问用户帐号的成功和不成功的历史记录 口令的包括：

• 第一次使用时强迫修改初始的口令 • 适当的最小的口令长度

• 适当的和强迫执行的口令修改的频率

• 依照不允许值清单的口令检查（如字典检查） • 紧急情况口令的足够的保护 正式的问题解决程序包括：

• 5次重复的不成功的登录企图以后，用户ID要暂停

• 最近访问的日期、时间以及不成功企图的数量在登录时显示给授权的用户 • 证明的时间在5分钟，这之后，会话就终止

评定遵从性：

• 用户暂停被通知，但是不告诉原因

程序中的拨号访问包括拨号的回拨或基于证明的标志、拨号号码的频繁改变、对资产访问的软件和硬件的防火墙、口令的频繁改变以及先前雇员口令的停用

位置控制方法被用来申请特定位置的附加

声音邮件服务和PBX系统的访问用与计算机系统相同的物理和逻辑控制而控制 强迫执行的敏感职位发生，包括：

• 在敏感工作职位的雇员历年被要求离开机构适当时间期间；在这一段时间期间，用户的ID被暂停使用；假如任何与安全相关的畸形被注意到时，代替该雇员的人被教导通知管理层

• 有时，涉及敏感活动的未经宣布的人员轮换被执行

与安全相关的硬件和软件，诸如密码模块要防止篡改或披露，访问被到“需要才能知道”这个基础上

安全数据的访问，诸如安全管理、敏感交易数据、口令和密码密钥被到“需要才能知道”这个基础上

信任的途径被用来传输非加密的敏感信息

为了防止由于垃圾传真的攻击而造成的服务拒绝，应采取如下保护措施： • 以“需要才能知道”为基础，传真号码披露给外部的组织 • 用于业务揽货的传真线路不能用于其它目的

关于计算机病毒的预防性和侦探性的控制措施已经由管理层所建立 为了强迫执行电子化价值的完整性，要采取如下措施： • 读卡机设备被保护以防止卡信息的毁坏、披露或修改 • 卡信息（PIN和其它信息）被保护以防止内部人员的披露 • 防止卡的伪造

为了强迫执行安全特征的保护，应采取如下措施： • 指定不活动期间以后，要求重复执行确认和证明过程

• 当终端单独被离开时，一键锁定系统，一个强有力的键或关掉顺序被激活

测试：

IT功能要符合下述相关安全标准： • 证明和访问

• 管理用户特征文件和数据安全的分类 • 违背和安全事变报告以及管理层评价 • 加密密钥管理标准

• 病毒的发现、解决和沟通 • 数据分类和所有权

请求、建立和维护用户访问系统的程序存在

外部访问系统资源的程序存在，也就是说，登录、ID、口令、回拨 访问装置完整性的详细目录被维护

操作系统的安全参数基于卖主和当地的标准 网络安全管理的实务被沟通、理解并强迫执行 外部访问提供者合同包括安全责任和程序的考虑 实际的系统、用户和外部卖主访问的登录程序存在 对事变作出及时、准确和管理响应的安全报告正在发生 传输所使用的秘密密钥存在 防止恶意软件的程序包括：

• 由机构获取的所有软件要先于其安装和使用进行病毒检查

控制的IT过程： 确认和分配成本 满足的业务需求：

证实没有满足业务目标的风险：

6 确认和分配成本（DS6）

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的信息系统安全的基准 信息系统安全的详细评价，包括计算机和通信资源等的物理和逻辑安全的穿透评估

确定安全意识和个人责任的新的雇员的访谈（也就是说，确认签署的安全陈述和新的雇员有关安全的培训）

确定访问是按业务需要（最小的要求）而决定并由管理层对其精确性进行有规律地评价的用户的访谈， 确定：

不适当的系统资源的用户访问

与网络的示意图或者与缺少的访问点、缺少的附件等等相关的详细目录的矛盾

在发送和接收者传输之间任何点上，与所有者以及有关数据完整性和安全责任相关的合同的不足 没有被作为合法用户而检验的雇员，或者已经分离的先前的仍然具有访问权的雇员 非正式的或没有通过的访问系统资源的请求

不能对网络管理的安全违背进行报警的网络监控软件 网络软件变更控制程序的短处

在第三方提出/接受程序中，不使用秘密密钥

密钥的产生、分发、存储、登录、使用、存档和保护的协议中的不足

不是最新的病毒发现软件，或者缺乏防止、检测、纠正和报告蔓延的正式的程序

• 有关免费软件和共享软件的下载、接受和使用的书面存在，并且要遵从这一

• 非常关键应用的软件要由MAC（消息证明码）或数字签名保护，检验防止软件被使用的失败 • 用户已经收到了有关病毒的发现和报告的指令，诸如行动迟缓的性能或者文件神秘的增长 •按照外部机构的标准购买程序，对购买的磁盘进行检查的和程序存 防火墙起码要具有下列特性：

• 从内部到外部所有的交易，或者相反，必须经过防火墙（这些不但在逻辑的控制，而且也要在物理上强迫执行）

• 仅有由本地安全所定义的授权的交易被允许通过 • 防火墙自身对穿透是免疫的

• 交易只能在应用层上通过防火墙交换

• 防火墙体系结构联合应用和网络层两者的控制措施 • 防火墙体系结构在传输层上强迫执行非连接协议

• 防火墙体系结构应该按照“最小的艺术理念”而配置 • 防火墙体系结构应该为其组件的管理部署强有力的证明 • 防火墙体系结构隐藏内部网络的结构

• 防火墙体系结构提供所有与防火墙系统通信或者穿过的额审计痕迹，当可疑的活动被发现时，将产生报警

• 对来自公共网络的输入服务请求提供支持的机构的主机，搁置在防火墙之外

• 防火墙体系结构防护自身避免直接的攻击（如，通过对交易的活跃性监控和模式识别技术）

• 在引入到内部网络之前，所有的可执行代码要针对恶意代码（如病毒、恶意java的程序）进行扫描

获得了解：

6.1 收费项目

6.2 成本核算程序

6.3 用户付费和费用返还程序

访谈：

IT行政管理或成本分配管理层

被挑选的返款及分摊成本的用户管理层 获得：

接受高级管理层指导的IT管理层，应确保收费项目可以由用户确认、测量和预测。用户应能够控制信息服务的使用和相关的付费水平。

IT管理层应定义并使用付费和费用返还程序。应维护用户付费和费用返还程序，该程序鼓励计算机资源的适当使用，并确保公平对待用户部门和他们的需求。费用比率应反映所提供服务的相关成本。

IT管理层应定义并执行成本核算程序，提供有关释放信息服务成本方面的管理信息，同时确保成本的有效性。对成本预算和实际执行的差异，应充分分析和报告，以促进成本的监控。另外，管理层应根据机构的其它财务测量系统，定期地评估IT职能部门的工作成本核算程序的结果。

确保可归因于IT服务成本的正确认识 实现路线：

一个成本会计系统，该系统确保成本被记录、计算并分配到所要求的具体层次和所提供适当的服务上 需要考虑的事项：

资源的可确定性和可测量性 收费和程序

费用率及费用返还的过程 与服务水平协议的联系 自动化的报告 收益实现的确认 外部基准 信息规范 IT资源 效果 * 人员 P 效率 * 应用 保密 * 技术 完整 * 设施 可用 * 数据 遵从 P 可靠

对高级和详细的控制目标进行审计：

评估控制：

与计划编制和预算准备相关的机构范围内的和程序

与成本集结、返款方法和绩效/成本报告相关的IT和程序 IT职能部门的：

• 当前和以前年度的预算 • IT资源利用的跟踪报告

• 在准备跟踪报告中使用的原始数据 • 成本分配方法或算法 • 历史性的返款报告 用户管理层的：

• 当前和以前年度的IT成本预算

• 当前年度的信息系统开发和维护计划 • IT资源的预算开支，包括那些返款或分摊

考虑是否：

IT职能部门有一个小组，负责报告并发布返款单给用户 下列程序要到位：

• 开发每年的开发和维护计划，这一计划是用户确认的开发、维护和操作开支 • 考虑非常高的层次的用户决定，就是IT资源应该投向何处 • 产生一个每年的IT预算，包括： • 遵从预算准备方面的机构的需求 • 与由用户部门所分配的成本一致

• 历史成本的沟通、新成本的假定——由用户了解返款中包括什么成本 • 由用户签署由IT职能部门分配的所有预算成本 • 报告的频率和用户成本的实际收费

• 跟踪所有IT资源的分配成本，但不限于此： • 操作的硬件 • 外围设备 • 电信的使用 • 应用开发和支持 • 行政管理的开销

• 外部卖主的服务成本 • “帮助工作台” • 设施和维护 • 直接/间接成本 • 固定和可变的开支 • 滞留和任意的成本

• 有规律地报告给用户有关各种不同的成本分类的性能

• 报告给用户关于成本效益的外部基准，以便允许与行业预期或用户可选择的服务来源进行比较 • 反映正在变化的业务需求的成本分配的及时修改 • 收到的费用的正式通过和接受

• 确认IT进步的机遇，以减少返款或得到返款的更大的价值 报告提供收费条款是可确认的、可测量的和可预测的保证 在基础成本组件或分配算法方面，报告要捕捉并突出变化

评定遵从性：

证实没有满足业务目标的风险：

测试：

成本分配算法存在，其公平性得到了用户的同意，正在生成成本和报告两者，参考：确认的计算 减少成本或增加IT资源性能的改进程序存在

分配和报告鼓励最适当、有效和一致的IT资源的使用，确保公平对待用户部门和它们的需求，费用率反映提供服务的相关成本

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的成本会计和返款方法的基准 通过返款分配算法并深入到用户报告流之中，将来自原始数据的返款再计算 进入到性能报告中的数据是精确的，诸如： • CPU的使用

• 外围设备的使用 • DASD的使用 •代码行的书写 • 行/页的打印 • 程序变更的产生

• PC机、电话、数据文件的数量 • “帮助工作台”的查询 • 传输的数量、长度

进入性能报告的原始信息资源数据的编辑是正确的 编辑并分配成本进入返款的实际算法存在 给特定用户的返款的精确度被频繁地测试 用户的返款被通过

在不同用户之中返款的一致性检查

有关用户开发计划的进步是基于已支出的成本 使用的报告奋发评价和成本信息 用户下列满意度的评价：

• 依照预算的预期的返款的合理性

• 每年的与收费返回成本相对的开发计划进步

• 依照可选择的来源（也就是基准）的返款的合理性 • 增加/减少返款的趋势的沟通 • 来自期望返款的差异的解决 确定：

增强的效果的机遇以及适当的返款方法 • 包括更多的成本组件

• 修改成本分配索引或测量单位 • 修改成本算法本身

• 机械化或集成设备与应用生成报告之间的工作会计职能 分配算法之内的矛盾 不同用户之中分配的矛盾 系统资源改进的机遇

用户更好地应用IT资源来完成用户业务需求的改进的机遇

在转化改进的性能或为提供的服务较少的用户成本的收集、积累、分配报告和沟通过程中的改进的效

率

来

7.2 培训机构

7.1培训需求的确定

7.3 安全准则和意识的培训

7 教育与培训用户（DS7）

控制的IT过程： 教育和培训用户 满足的业务需求：

确保用户在有效地使用技术，并意识到风险以及应负的责任 实现路线：

一个全面的培训与发展计划 需要考虑的事项： 培训课程表

技能的详细目录 认知运动 认知技术

新培训技术与方法的使用 人员的生产力 知识库的开发 信息规范 IT资源 P 效果 * 人员 S 效率 应用 保密 技术 完整 设施 可用 数据 遵从 可靠

基于所确定的需求之上，管理层应定义目标组，确定并指定培训教师，及时机构培训课程。可选择培训的有关事项也应进行调查（内部场所还是外部场所、内部培训教师或是第三方培训教师等）。

根据长期计划，管理层应建立并维护一个程序，来确认并归档所有使用信息服务的人员的培训需求。应建立针对每一个雇员组的培训课程表。

所有人员必须在系统安全准则方面接受培训和教育，包括要特别关注安全意识和突发事件处理方面的定期更新。管理层应提供一个教育和培训程序，该程序包括：IT职能部门的行为规范，防止影响到有效性、保密性、完备性危害的安全实务以及以安全的方式履行职责。

由差异和分析所反映的成本趋势被转化成下一期和成本结构中所反映的修改的收费

使IT职能部门成为一个利润中心而不是一个给其它内部或外部用户提供服务的成本中心的机遇存在， 如果IT职能部门是一个利润中心，依照计划和预算的利润贡献被满足，增长的收益率的机遇被勾画出

遇

评估控制：

获得了解：

评定遵从性：

对高级和详细的控制目标进行审计：

访谈：

机构的人力资源或培训经理 IT人力资源或培训经理

挑选的IT职能部门的经理和雇员 挑选的用户部门的经理和雇员 获得：

与控制和安全意识培训相关的机构范围内的和程序，开发地聚焦在雇员的收益、服务培训程序的用户、教育资源设施以及职业持续教育需求上

与控制和安全意识、技术安全和控制相关的有关培训和教育的IT软件、和程序

介绍性的、正在进行的安全和控制意识以及机构内培训的可用的培训程序（内部和外部两者）

在正在进行的基础上，雇员被要求参加安全和控制认识的培训，这些基础包括但不限于此： • 总体的系统安全原则 • 与IT相关的伦理行为

• 避免来自影响可用性、秘密性、完整性以及安全方式义务执行失败伤害的安全实务 • 与IT资源的保管和使用相联系的责任

• 当非现场使用时，信息和信息系统的安全

安全认识培训包括防止通过交谈而造成的敏感信息透露的（如通过将信息的状况宣布给所有参加交谈的人员）

考虑是否：

与正在进行的安全和控制认识相关的和程序存在

具有一个聚焦在信息系统安全和控制原则上的教育/培训程序

要使新的雇员产生有关IT资源的使用和具有保管的安全和控制责任的认识 具有有效联系培训的和程序，关于IT资源的技术配置是最近的 内部培训机遇的可用性，雇员出席的频率 外部技术培训机遇的可用性和雇员出席的频率

培训职能部门正在评估有关安全和控制的个人的培训需求，并将这些需求转化成内部或外部的培训机

测试：

新的雇员已经认识并理解拥有和使用IT资源的安全、控制和信用的责任

雇员关于所有IT资源的秘密性、完整性、可用性、可靠性和安全性的责任以正在进行的基础上被沟通 IT职能部门内的一个小组正式负责IT的培训、安全和控制意识以及专业认证的持续教育程序的维护 正在进行的雇员培训需求的评估被说明

与安全和控制相关的培训项目的开发或参加是培训需求的一个部分 新的和长期的雇员安全意识的实际培训项目存在 利害声明的机密性和冲突由所有雇员签署

8.1 帮助桌面

没有缺失雇员利害声明的机密性和冲突 没有缺失雇员的培训需求评估

控制的IT过程： 帮助及向客户提建议 满足的业务需求：

确保适当地解决用户经历的任何问题 实现路线：

提供一线支持和建议的“帮助桌面”设备 需要考虑的事项： 客户质询和问题响应 质询监控和清理 趋势分析和报告 知识库的开发 根源原因分析

问题的追踪和逐步升级 信息规范 IT资源 P 效果 * 人员 P 效率 * 应用 保密 技术 完整 设施 可用 数据 遵从 可靠

8.2 客户质询的登记

证实没有满足业务目标的风险：

8 帮助及向客户提建议（DS8）

应有一个程序，确保所有的客户质询由“帮助桌面”适当地登记下来。

执行：

关于安全、机密性、可靠性、可用性和完整性控制方面，培训手册的适当性和充足性的评价 决定培训需求和履行这些需求的范围确认的IT职员的访谈 确定：

响应培训需求的所提供课程的矛盾

与IT资源的使用相关的安全和内部控制问题的用户认识的不足

应在“帮助桌面”职能部门内建立用户支持。履行这一职能责任的个体应与问题管理人员紧密地交互。

评估控制：

获得了解：

8.4 清理的监控

8.5 趋势分析和报告

8.3 客户质询的逐步升级

对高级和详细的控制目标进行审计：

访谈：

IT“帮助工作台”支持经理 被挑选的信息服务的用户 获得：

与IT用户支持相关的机构范围的和程序

与“帮助工作台”活动相关的IT的宪章、使命、组织机构图以及社程序 与用户的质询、质询的解决、“帮助工作台”的性能统计相关的报告 “帮助工作台”活动的任何性能标准

IT职能部门和各种不同用户之间的服务水平协议 勾画“帮助工作台”人员经验和专业证书的个人文件

应建立一个程序，确保有关客户质询和解决、响应时间以及趋势确认的适当报告。报告应被适当地分析并要采取行动。

考虑是否：

“帮助工作台”功能的本性（也就是说，帮助请求怎样被处理，以及怎样被提供）是有效的 实际的设施、部门或机关正在执行“帮助工作台”功能，个人或职位对“帮助工作台”负责 “帮助工作台”活动的文档水平是足够的和当前的 登录或服务的请求以及日志使用的实际过程存在

质询的逐步升级以及解决问题的管理层介入的过程是充分的 清除收到质询的时间框架是适当的

“帮助工作台”活动的趋势追踪和报告的程序存在 性能改进的主动权被正式地确认和执行 服务水平协议和性能标准正在被满足 用户满意度水平被定期地决定和报告

“帮助桌面”程序应确保那些不能马上解决的客户质询，被适当地在IT职能部门内部升级。

管理层应建立一个程序，用于及时监控客户质询的清理。长期突出的质询应被调查并要采取行动。

评定遵从性：

9 管理配置（DS9）

证实没有满足业务目标的风险：

测试：

与“帮助工作台”活动相关的和程序是当前的和精确的 服务水平的委托正在被保持，不一致被解释 质询的清除正在以及时的方式发生

趋势分析和报告正在提供下述的保证：

• 报告被产生以及趋势被采取行动是为了改进服务 • 报告包括特定的问题、趋势分析以及响应时间 • 报告交付给有解决问题权利的责任人

帮助请求、准确性的确认、响应的及时性和充足性的样本 用户满意度水平的查询并采取行动

执行：

确定下列满意度的挑选用户的访谈： • “帮助工作台”活动 • 活动报告

• 服务水平委托的会议

关于执行义务所具有的“帮助工作台”人员的资格和能力的评价 挑选的逐步升级的质询的响应适当性的评价 趋势以及可能的性能提高机遇的报告的评价 确定：

关于与IT职能部门内其它机构，也包括用户组织的“帮助工作台”活动的不充分的交互 与问题报告质询收据、注册、日志、追踪、逐步升级和解决相关的不充分的程序和活动 缺乏管理上的介入或有效正确的行动的有缺陷的逐步升级过程 不适当及时的问题报告或用户不满的问题报告过程

控制的IT过程： 管理配置

满足的业务需求：

说明所有IT部件，防止未经授权的变更，核实物理的存在，并为健全的变更管理提供基础 实现路线：

确定并记录所有的IT资产及其物理存放位置的控制，有规律地校验其存在的程序 需要考虑的事项： 资产的追踪 配置变更管理 未授权软件的检查 软件存储控制

软件和硬件相互关系和集成 自动化工具的使用 信息规范 IT资源 P 效果 人员

效率 保密 完整 S 可用 遵从 S 可靠

9.6 软件存储

9.4 配置控制

9.3 状态说明

9.2 配置的底线

9.1 配置的记录

9.8 软件可说明性

9.7 配置管理程序

9.5 未授权的软件

* 应用 * 技术 * 设施 数据

应建立程序确保IT配置记录的实物存在和一致性的定期检查。

IT管理层应确保配置记录反映全部配置条款，包括变更历史的实际状态。

IT管理层应确保配置条款的底线得到保持，以作为变更以后回退的检查点。

应开发并强制执行个人使用和无许可证软件的明确。机构应使用病毒检测和补救软件。业务和IT管理层应定期检查机构的个人计算机以发现未经授权的软件。应定期评价遵循软件和硬件许可证协议的要求。

应存在一个程序，确保只有授权和确认的配置条款被记录在获取物品的清单中。这些程序也应规定授权处置和相因而生的配置条款的出售。此外，还应建立程序保持对配置变更（如，新的条款、从开发到原型的状态变化）的追踪。日志和控制应当是配置记录系统完整的一部分，包括变更记录的评价。

对于系统开发生命周期适当阶段的所有有效的软件项，应定义一个文件存储区域（库）。这些区域应彼此分离，开发、测试和生产文件存储区域要彼此隔离。

应建立配置管理程序，确保机构IT资源的关键组成部分被适当地确定和维护。应有一个完整的程序，藉此，测量当前和未来的处理要求，并作为输入提供给IT资源的获取程序。

软件应标注、造册并适当地许可。库管理软件应被用来产生程序变更的审计痕迹，并维护程序版本号、

创建日期信息和以前版本的拷贝。

评估控制：

获得了解：

对高级和详细的控制目标进行审计：

考虑是否：

创造和控制配置底线（配置条款的设计和开发的分界点，没有经历严格的配置控制，超出这一分界点发展就不能发生）的过程是适当的

维护配置底线的职能存在

购买和租用资源的会计核算控制状况的过程——包括输入、输出以及与其它过程的集成——存在 配置控制程序包括： • 配置底线的完整性

• 变更管理系统的可编程访问授权控制

• 配置条款的恢复以及任意一点的及时的变更请求 • 评估配置记录程序适当性的配置和报告的完成 • 配置记录功能的定期的评估

• 负责评价配置控制的人员具有必备的知识、技能和能力 • 评价访问软件底线的程序存在

• 评价的结果提供给管理层进行纠正行动

存货和会计记录配置的定期评价有规律地执行 配置底线具有追踪变化的足够的历史

访谈：

IT操作管理层 IT系统支持管理层 IT应用开发管理层 设施管理层

软件卖主支持人员

与计算机相关的资产管理人员 质量保证经理 获得：

配置的详细目录：硬件、操作系统软件、应用软件、设施和数据文件——现场和非现场

与购买、出租以及租用的计算机有关的设备和软件的获取、存货和处置相关的机构的和程序 与未授权软件或设备使用相关的机构的

与特定的配置资源的获取、处置和维护相关的IT的和程序

质量保证以及地将新的或修改的软件从开发移动到生产状态和文件的移动和记录的变更控制功能的IT的和程序

配置的底线信息

与系统资源相关的固定资产和租用的会计记录 与增加、删除和改变系统配置相关的报告 各种不同库内容的清单——测试、开发和生产

非现场存储内容的详细目录——设备、文件、手册和表格——包括在供应商手里的资料

评定遵从性：

测试：

所有的配置条款都在底线控制之下

与配置报告相关的和程序是当前的和精确的 关于配置维护和报告的性能标准被遵守

配置底线依照设备的物理详细目录和资产的会计记录的比较正在发生 的测试到生产转移和变更记录的存在 为了底线输出的选择：

• 精确、适当和通过的配置条款底线被保持

• 配置记录反映了所有配置条款的实际状态，包括历史的变化

• 配置记录的一致性被定期地评价，并由管理层评估，纠正行动被采取 • 在系统开发生命周期中的适当的阶段，文件库被适当地和充分地定义

• 任何包含未授权软件的个人计算机、违背被报告，管理层要采取纠正行动 • 关于所有卖主提供资源的产品、版本和修改的配置记录是精确的 • 配置变更的历史记录是精确的

• 确保没有未授权软件的机制在计算机之上，包括： • 和声明

软件变更控制程序存在：

• 建立并维护得到许可的应用程序库

• 确保得到许可的应用程序库被适当地控制 • 确保软件详细目录可靠性和完整性

• 确保使用的授权软件详细目录的可靠性和完整性，检查未授权软件 • 分配未授权软件控制的责任给特定的班子成员

• 记录未授权软件的使用，并报告给管理层进行纠正行动 • 决定是否管理层在违背方面采取了纠正行动

将开发应用移动到测试环境中，并最终移动到生产状态下的过程要与配置报告相互影响 软件的存储过程包括：

• 对于所有的有效软件，在系统开发生命周期中的适当阶段，定义安全的文件存储区域（库） • 要求软件存储库彼此之间要分开成为开发、测试和生产文件存储区 • 要求在允许移动到生产周期时期的源模块的临时位置在源库内存在 • 要求所有库的每一个成员都分给一个所有者 • 定义逻辑和物理访问控制 • 建立软件的问责制 • 建立审计痕迹

• 检测、形成文档并向管理层报告不遵从这一程序的所有例子 • 决定管理层是否采取了纠正行动

关于依照变化更新配置底线方面，应用开发、质量保证和操作之中的协调正在发生 软件被标注并定期地清点存货 库管理软件被用于：

• 产生程序变化的审计痕迹 • 维护程序的版本号

• 记录和报告程序的变化

• 维护生产模块的创造/日期信息 • 维护先前版本的拷贝 • 控制并发的更新

证实没有满足业务目标的风险：

10 管理问题和事件（DS10）

• 潜在义务的培训和认识（法律和产品）

• 由所有使用计算机的人员签名的遵从性的形式 • 计算机软件的集中控制

• 计算机软件的正在进行的评价 • 评价结果的报告

• 以评价结果为基础，由管理层所进行的纠正行动

• 开发周期期间，应用程序的存储和源码被决定，配置记录的影响正在被确定

• 与配置相关的非现场和卖主记录的充足性和完整性以及配置记录的精确性正在被先期发生和考虑 • 配置底线程序规定：

• 记录创造底线的事件、底线的建立以及底线中被控制的配置条款

• 正在变化着的底线，包括要求通过先前已经通过的配置底线的变化的权利 • 记录底线的变化以及在底线中被控制的配置条款 • 确保所有的配置条款被记录到底线产品中 • 状态会计报告正在发生：

• 被采集、存储、处理和报告的信息类型（应该包括底线的状态；底线评价的发现；变更请求和状态；配置控制委员会（如果适用）评价和通过/没有通过；实际产生的变更；麻烦报告和状态；配置的修订历史）

• 用不完全的状态会计核算怎样解决变更请求问题 • 产生的状态会计核算报告的类型和频率 • 这一状态数据的访问怎样被控制

执行：

配置记录的管理评价以及记录的变更、详细目录、会计核算和卖主记录的调整的频率和及时性的详细评价

为了可能的复制、丢失目标码的确认，并为了消除不需要的数据或程序文件——并反映在配置记录中，各种不同库的计算机化软件的分析

确定：

关于下述管理和人员认识以及对机构的理解方面的弱点： • 配置记录以及这些记录的变化

• 在系统开发生命周期中配置控制的布置 • 配置、会计核算和卖主记录的集成 • 不在个人计算机上使用未授权的软件

在底线配置创造和维护功能的效果和效率方面，可能改进的不适当性

反映在配置记录、记录安全或由卖主进行的适当反映记录改变的卖主变化中的不足

控制的IT过程： 管理问题和事件 满足的业务需求：

确保问题和事件的解决，并调查原因，防止再现 实现路线：

一个记录和改进所有事件的问题管理系统 需要考虑的事项：

10.2 问题升级

10.1 问题管理系统

问题和解决方案的审计痕迹 所报告问题的及时解决 逐步升级程序 事件报告

配置信息的可达性 供货商的责任 与变更管理的协调 信息规范 IT资源 P 效果 * 人员 P 效率 * 应用 保密 * 技术 完整 * 设施 S 可用 * 数据 遵从 可靠

10.3 问题跟踪和审计痕迹

10.4 应急和临时访问的授权

10.5 紧急事件处理的优先顺序

紧急和临时访问的授权应备有标准格式的证明文档，并以文件的形式维护，由适当的管理者审批，并与安全职能部门安全地交流沟通，在预先设定的时间段后自动终止。

IT管理层应定义并实施一个问题管理系统，确保所有非标准操作部分（事件、问题和错误）的操作事件被记录、分析并及时加以解决。紧急事件流程的变更程序应迅速地测试、归档、审准和报告。重大问题发生时，应建立事件报告。

IT管理层应定义并实施问题逐步升级程序，确保确认的问题以最有效、及时的方式加以解决。这些程序应确保这些问题的优先级顺序的适当设定。对于IT持续性计划的激活来讲，此程序亦应载明逐步升级的过程。

问题管理系统应规定适当的审计痕迹装置，它将允许事件开始到潜在原因的跟踪（如，软件发布或紧急变更的执行等）和相反方向。它应与变更管理、可用性管理和配置管理紧密地交织在一起。

紧急事件处理的优先顺序应被建立、备有证明文档，并由适当的程序和IT管理层所批准。

评估控制：

获得了解：

对高级和详细的控制目标进行审计：

访谈：

IT操作支持人员

IT“帮助工作台”支持人员 IT系统支持人员 IT应用支持人员 挑选的IT资源的用户 获得：

问题管理设施的概述以及履行问题管理职能的职位

与问题管理相关的IT和程序，包括认识、记录、逐步升级、追踪和报告过程 在代表性期间被报告问题的明细表，包括发生的日期、日期的逐步扩大（如果适用）、解决的日期以及解决的时间框架

立即逐步升级以作为优先解决或作为关键问题报告引起高级管理层注意的关键应用的详细目录 任何问题管理应用的理解，特别是确保所有问题被捕捉、解决和按照所要求的报告的方法

考虑是否：

具有一个确保所有的不是标准操作一部分的操作事件以及时的方式被记录、分析和解决的问题管理过程，对于重大的问题，要产生事件报告

下列问题管理程序存在：

• 定义并执行一个问题管理系统

• 以及时的方式，记录、分析、解决所有的非标准事件 • 对关键的事件建立事件报告，并报告给用户

• 确认问题类型，允许针对以风险为基础的变化多样的解决努力，排出优先顺序的方法 • 定义问题管理信息的逻辑和物理控制

• 按照“需要才能知道”的原则，分发输出 • 问题趋势的追踪，以最大化资源，减少维修

• 采集精确的、当前的、一致的和有用的数据输入给报告 • 为了逐步升级和认识，通知适当级别的管理层

• 为了增加效果和效率，决定管理层是否定期评估问题管理过程 • 系统问题的审计痕迹的充分性

• 与变更、可用性、配置管理系统和人员集成

紧急情况处理的优先顺序存在，形成文档，并要求由适当的程序和IT管理层通过 具有紧急状况和临时的访问授权程序，它们要求： • 标准形式的访问文档并以文件的形式维护 • 由适当的经理所通过 • 安全职能的安全的交流

• 预定的时间期间以后，自动的访问终结

评定遵从性：

11 管理数据（DS11）

证实没有满足业务目标的风险：

控制的IT过程： 管理数据

满足的业务需求：

确保数据在输入、更新和存储期间的完整、准确和有效 实现路线：

有关IT操作的应用和全面控制的有效组合 需要考虑的事项： 形式的设计 源文档控制

输入、处理和输出控制 媒介确认、移动和库管理 数据备份和恢复 鉴别和完整性 数据所有权 数据管理

数据模型和数据表示标准 跨平台的集成和一致性

测试：

与下述相关的、遵从所述程序的过程输出的挑选样本： • 没有关键的问题

• 较高优先顺序/关键的问题需要逐步升级

• 报告需求、内容、精确、分发和所采取的行动 • 对问题管理过程和结果的用户满意度 通过访谈，问题管理过程的认识和理解

执行：

对于所选择的报告的问题，确保所有的非标准活动的问题管理程序被追随的测试，包括： • 由过程所产生的所有非标准的事件的记录 • 每一个和所有事件的追踪和解决

• 以事件的优先级为基础的响应的适当水平 • 对于关键事件的问题的逐步升级

• 在IT职能部门和用户组之内的适当报告 • 过程改进效果和效率的有规律地评价 • 性能改进程序的预期和成功 确定：

没有由问题管理过程正式控制的问题的出现

在每一个问题管理过程中，认识到但没能解决的问题的出现 有关问题解决的实际和正式处理事件之间的差异

问题管理过程的用户短处，问题和解决的交流——对可能的改进机遇

法律和法规要求 信息规范 效果 效率 保密 P 完整 可用 遵从 P 可靠

11.1 数据准备程序

11.5 源数据资料的保留

11.3 源数据资料的收集

11.6 数据输入的授权程序

IT资源 人员 应用 技术 设施 * 数据

11.4 源数据资料的错误处理

11.2 源数据资料的授权程序

11.7 准确性、完整性和授权检查

应设置一个程序，确保原始的源数据资料由机构保留或者被复制足够的数量，既促进数据的修补或者重建，又满足法律的要求。

机构的程序应确保所有授权的源数据资料是完整、准确的，被适当地说明并以及时的方式传递给录入环节。

管理层应确保源数据资料由授权人员适当地准备，该授权人员在他们的授权范围内发挥作用，关于源数据资料的来源和审准，应存在适当的职责分离。

管理层应建立用户部门所遵循的数据准备程序。就此而论，输入形式的设计应有助于确保错误和遗漏的最小化。数据源期间，差错处理程序应适度地确保错误和不当得以检测、报告并纠正。

机构应建立合适的程序，确保数据只能由授权人员输入。

数据源期间，错误处理程序应适度地确保错误和不当被检测、报告并纠正。

录入处理的交易数据（人工产生、系统生成或者通过界面输入）应服从于准确性、完整性、合法性检查等多种控制。也应建立确保输入数据尽可能在接近于生成点被验证和编辑的程序。

11.13 输出的分发

11.14 输出平衡和勾对

11.9 数据处理的完整性

11.12 输出的处理和保留

11.8 数据输入错误的处理

11.16 输出报告的安全规定

11.11 数据处理的差错处理

11.15 输出的评价和差错处理

11.10 数据处理的确认和编辑

机构应建立错误输入数据的纠正和再次提交的程序。

对于IT输出的分发来讲，机构应建立并沟通书面的程序。

机构应建立一个程序，确保输出与相关的控键总计例行地进行平衡。应提供审计痕迹，以便促进交易处理的追踪和被中断数据的勾对。

机构应为来自于IT应用程序输出的处理和保留建立程序，万一可转让的装置（如储值卡）是输出的接受者，应采取特殊的关注以防止误用。

机构应建立程序，确保数据处理的确认、真实性鉴别和编辑被尽可能地接近于数据产生点执行。当使用人工智能系统时，这些系统应被放置在一个与真正的操作员交互的控制架构中，确保那些至关重要的决策得到审批。

机构的管理应建立一个程序，确保输出报告的正确性得到提供者和相关用户的评价。也应存在一个控制输出中错误的程序。

机构应为数据处理建立一个程序，确保维持职责分离并例行校验所执行的工作。程序应确保适当的更新控制，如RUN-TO-RUN控键总计和主文件更新控制。

机构应建立数据处理的差错处理程序，使错误的交易能够不被处理并且不会引起其它正确交易处理非法中断的条件下确定下来。

机构应建立程序，为了这些等待发布的输出报告，确保其安全得到维护，如同它们已经发布给了用户。

11.25 备份存储

11.24 备份工作

11.19 存储管理

11.23 备份和恢复

11.22 介质库管理责任

11.21 介质库管理系统

11.20 保留周期和存储期限

11.18 废弃的敏感信息的保护

11.17 传输和传递期间对敏感信息的保护

应开发一个考虑恢复需求、成本/效益和安全的数据存储程序。

管理层应确保传输和传递过程中对敏感信息的充分保护，防止未经授权的访问、修改和寄错。

管理层应为备份和恢复而执行一套适当的，确保包括业务需求的评价以及恢复计划的开发、执行、测试和建档。应当设立程序，确保备份满足上述需求。

IT相关介质的备份程序应包括数据文件、软件和相关文档的现场与非现场的适当存储。备份应安全地存储，对于物理访问安全和数据文件以及其它事项的安全来讲，要定期评价存储地点。

应当存在一个程序，确保备份的执行符合已经定义的备份策略，并且应对备份的可用性进行有规律地检验。

IT职能部门应建立这样的程序，以确保包含数据的介质库内容被系统化地盘存，由物理盘存所暴露出来的任何差异要以及时的方式补救，要采取措施维护存储在库中磁介质的完整性。

管理层应定义并执行一个程序，当计算机、磁盘、其它设备或介质废弃或传递给其他人使用时，要防止对其中的敏感信息和软件的访问。这样的程序应保证标记着删除或废弃的数据不能由内部或第三方恢复出来。

应定义文档、数据、程序、报告和信息（输入和输出）的保留周期和存储期限，用于加密及身份鉴别的数据（密钥、证书）也同样需要定义。

IT管理层应建立设计用于保护介质库内容的内务管理程序。对于磁介质的外在辨识及物理移动和存储的控制来讲，应当定义标准，以支持问责制。介质（磁带、盒式磁带、磁盘和磁碟）库的管理责任应分配给专门的IT职能人员。

获得了解：

11.26 归档

11.28 鉴别和完整性

11.27 敏感信息的保护

11.29 电子交易的完整性

11.30 存储数据的持续完整性

管理层应确保存储在文件和其它介质（如电子卡）中的数据的完整性和正确性被定期地检查。要对那些代币信息、证明文件以及包含私密性信息的文件给予特别的关注。

对于在因特网和任何其它公共网络上的数据传输，管理层应定义并执行程序及协议，用来确保敏感信息的完整性、保密性和不可否认性。

在执行潜在的关键行动之前，对源于机构之外的信息，无论是电话、声音邮件、纸面文档、传真，还是电子邮件，其真实性和完整性都要得到充分检查。

考虑到电子交易较少依赖传统的时间和地理边界，管理层应为敏感和关键的电子交易定义并执行适当的程序，确保以下方面的完整性和真实性:

原子性（不可分割的工作单元，所有行动要么全部成功要么全部失败）

一致性（如果交易不能达到稳定的结束状态，则系统必须恢复到初始的状态） 孤立性（一个交易的行为不受其它并发交易的影响）

持久性（交易一旦提交出去，交易的影响总是有效，系统失败不应改变交易本身）

访谈：

IT操作管理层

IT数据库管理员管理层 IT应用开发管理层

IT人力资源/培训管理层 IT系统支持管理层

备份场所安全和行政管理管理层

关键性任务应用的各种不同的用户管理层 获得：

与数据的性质和管理相关的机构和程序，包括： • IT职能部门内和到/来自数据用户的数据流转

管理层应执行一个和程序，确保归档符合法律和业务需求，并被适当保护和说明。

对高级和详细的控制目标进行审计：

评估控制：

• 机构中数据的起源、批处理、输入、处理、输出、评价、纠正和再提交以及分发给用户的点 • 源文档的授权过程

• 数据的采集、追踪和传输过程

• 确保输入的完成源文档的完整性、精确性、会计核算和传输的程序 • 数据起源期间，用于确认和纠正错误的程序

• 确保在Internet或任何其它公共网络上传输的敏感信息的完整性、机密性和不可否认性的程序 • 机构用来保留源文档（存档、成像等等）的方法，什么样的文档应该保留，法律和规章的保留要求等等

• 为IT职能部门提供数据和使用IT职能部门数据的接口系统 • 执行数据管理任务的卖主合同

• 用于监控活动和详细目录的管理报告

与下述相关的所有主要应用和用户文档的清单： • 执行输入精确性、完整性和授权检查的模块 • 每一个应用执行数据录入的功能 • 执行数据录入差错纠正例程的功能 • 用于防止（手工和程序手段）、发现和纠正差错的方法 • 控制提交数据的处理的完整性

• 与起源点尽可能近的数据处理编辑验证和证明 • 由应用所创造的输出的处理和保留

• 输出、输出的分发和使用输出的接口系统 • 平衡输出到控制总数并调解差异的程序 • 评价输出报告和信息的精确性 • 被分发的处理输出报告的安全

• 被传输的数据以及应用之间的安全 • 敏感的输入、处理和输出文档的处置

• 有关准备、输入、处理和输出的第三方卖主控制程序 与机构的任何中心数据库仓库相关的和程序，包括： • 数据库组织和数据字典 • 数据库维护和安全程序 • 数据库所有权的决定和维护

• 有关数据库设计和内容的变更控制程序 • 定义数据库活动的管理报告和审计痕迹

与数据的媒介库和非现场存储相关的和程序，包括： • 管理媒介库和库的管理系统 • 要求所有媒介的外部确认

• 要求所有内容的当前详细目录以及控制活动的过程 • 保护数据资源的内务处理程序 • 实际和数据记录之间的调解程序

• 满足数据媒介的重新使用和循环使用的数据

• 详细目录的过去测试数据以及被执行的恢复测试 • 在持续性计划中，媒介和非现场人员的角色

考虑是否： 数据准备：

• 数据准备程序确保完整性、精确性和有效性

• 对所有源文档的授权程序存在

• 起源、通过以及源文档转换成数据之间的职责分离正在发生

• 从源文档的起源开始，被授权的数据仍然是完整、精确和有效的 • 数据以及时的方式被传输

• 对源文档适当的完成和通过的定期评价发生 • 错误的源文档的适当处理

• 为了保护源文档避免妥协处理，关于敏感信息的充分控制存在

• 程序确保源文档完整性和精确性、源文档的适当的会计核算以及及时的转换

• 源文档的保留期是足够的长，以允许在损失、评价和审计的可用性、起诉调查或规章需求的事件发生时重建

数据输入：

• 先于录入，为了通过，适当的源文档的确定路线

• 提交、通过、授权和数据录入功能之间的适当的职责分离 • 不同的终端或站点代码以及安全操作员认证 • 站点代码和操作员ID的使用、维护和控制 • 确认输入源的审计痕迹

• 在尽可能与起源点近的地方进行输入数据的日常检验或编辑检查 • 错误输入数据的适当处理

• 对强制执行的数据方面的适当授权来讲，清晰地分配责任 数据处理：

程序包含差错预防、发现、纠正例程：

• 程序必须测试输入的差错（也就是说，检验和编辑） • 程序必须依照同样的主数据清单，检验所有的交易 • 程序必须不许差错条件的无视 差错处理程序包括：

• 差错的纠正和重新提交必须被通过 • 悬而未决文件的个人责任被定义

• 悬而未决文件产生没能解决差错的报告

• 以时期和类型为基础的悬而未决文件的优先顺序方案是可能的 被执行程序的日志以及被处理/被拒绝交易的审计痕迹存在

一个监控录入活动并调查非标准事件的控制小组，与平衡记录合计与所有被处理数据总计一起 即使一个域有了差错，所有的域都要被适当地修订 用于检验的表要频繁地评价

差错时纠正并重新提交数据的书面程序存在，包括在处理的非中断的解决方案 重新提交的交易与原来的处理一样被准确地处理 差错纠正的责任属于原来提交的职能

“人工智能系统”被放置在与人类操作员交互的控制框架中，以确保生死攸关的决策被通过 输出、接口和分发：

输出的访问被物理和逻辑地在授权的人员 输出需要的正在进行的评价正在发生 输出例行平衡相关总计

审计痕迹存在，以促进交易处理的追踪和中断数据的调解

输出报告的准确度被评价，包含在输出中的差错由有认识能力的人员所控制 输出、接口和分发期间的安全问题的清晰的定义存在

任何阶段期间的安全违背的交流被沟通给管理层，采取行动并反映在适当的新的程序中 输出处置的过程和责任被清晰地定义

使用资料的毁坏被目击，但是处理之后就不在需要

为了以后发生事件的需要，所有的输入和输出媒介都要存储在非现场的位置

评定遵从性：

测试： 数据准备：

关于与数据录入而进行的授权、通过、准确度、完整性和收据相关的所陈述的程序，挑选的源文档的样本的一致性是显然的，数据录入本身是及时的

来源、输入和转换的人员知道并理解数据准备控制需求 数据输入：

提交测试数据（好的和错误的交易类型两者都有），确保准确性、完整性和授权检查被执行 对于选择的交易，在输入之前和之后，与主文件相比较 差错处理的保留、解决并适当的评价完整性存在 遵从已建立的和控制的差错处理的程序和行动 数据处理：

运行到运行总计和主文件更新控制被有效地使用 提交测试数据（好的和错误的交易类型两者都有），确保数据处理的检验、鉴别和编辑在离起源尽可能近的地方执行

遵从已建立的程序和控制，差错处理过程被执行

差错处理的保留、解决和适当地评价完整性存在，并正在适当地行使职责 差错处理的程序和行动遵从已经建立的程序和控制 数据输出、接口和分发： 输出例行地被相关总计所平衡

审计痕迹被提供，以促进交易处理的追踪和中断数据的调解 由提供者和相关用户对输出报告的准确性进行评价

差错处理的保留、解决和适当的评价完整性存在，并正在适当地行使职责

标注被删除标志的信息被改变是在它不再被检索的这种方式下 介质库：

介质库的内容被系统列入详细目录

由详细目录所披露的差异以及时的方式被补救

措施被采取，以维护存储在库中的磁介质的完整性 内务处理程序存在，以保护介质库的内容

介质库管理的责任已经被分配给了具体的IT班子成员 介质的备份和恢复战略存在

介质的备份按照已经定义的备份战略进行，备份的可用性要有规律地检验

介质备份被安全地存储，并且要对存储场所定期地进行有关物理访问安全、数据文件安全以及其它条款的评价

文档、数据、程序、报告和信息（进来的和出去的）同用于这些数据的加密和鉴定的数据（密钥、证书）一样，其保留期和存储条款被定义

除了纸的源文档的存储以外，电话会话也要被记录和保留——假如不与本地的隐私法相冲突——因为业务活动一部分的交易或其它活动传统上是在电话上实施的

符合法律、业务需求以及强迫执行的问责制和再现性，关于信息（数据和程序）的档案的适当的程序要到位

信息鉴定和完整性：

数据文件的完整性被定期地检查

通过电话或声音邮件，收到的来自机构之外的请求由回拨或其它鉴定手段所验证

一个预先安排的方法用于来源鉴定以及通过传真或图象系统接收的交易请求内容的检验 电子签名或证书被用于检验进来的电子文档的完整性和真实性

证实没有满足业务目标的风险：

差错处理程序和行动遵从已经建立的和控制

输出报告安全等待分发，与那些遵照已经建立的程序和过程已经分发给用户的一样 未授权的访问和修改的传输和运输期间，对敏感信息的适当的保护存在 处置敏感信息的程序和行动遵从已经建立的和控制 介质库：

介质库的内容被系统地列入详细目录，任何暴露的差异已及时的方式补救，维护存储在库中的介质的完整性的措施被采取

设计用来保护介质库内容的内务处理程序存在，并正在适当地行使职责 介质库管理的责任被适当地分配

介质库于准备、输入、处理和输出的职能部门 介质的备份和恢复战略是适当的

按照已经定义的备份战略，介质的备份正在适当地发生 介质存储场所物理上是安全的，详细懂得存货目录是当前的 数据存储考虑了恢复的需求和成本效果

文档、数据、程序和报告的保留期限和存储的条款是适当的 信息的鉴别和完整性：

适当的保护确保在Internet或其它公共网络上传输的敏感信息的完整性、机密性和不可否认性 错误地址信息的风险（通过信件、传真或电子邮件）由适当的程序所缓解

被正常应用到具体交易或过程，诸如传真或自动电话应答的控制，也可以应用到支持交易或过程（例如，个人计算机上的传真软件）的计算机系统

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的数据管理的基准 在下述期间，选择交易确认适当的处理： • 数据准备 • 输入处理 • 数据处理

• 输出、分发或集成

• 处理的所有阶段的差错处理

• 处理的所有阶段贯穿全部差错处理的数据的完整性 • 保留和毁坏

特别要测试下列内容：

• 在处理的每一个阶段期间的完整性、准确性和有效性 • 适当的通过和授权

• 预防、侦探和纠正控制的存在——在处理之内或者通过控制组的手工/程序的功能 • 最后必需评价的源文档的保留——与保留需求相一致 • 确定存在和准确性的恢复源文档和交易介质的选择

• 分析审计痕迹的可用性：存在，起源/操作员可辨认的，任何接口系统具有控制交易的同等水平 • 输入和处理程序的编辑特性，包括但不限于此： • 所需的域是空白 • 交易码的检验 • 数量是负值

• 所有其它适当的条件

• 内部处理的检验测试的充分性

• 有缺陷交易的悬而未决文件包括下列控制：

控制的IT过程：

12 管理设施（DS12）

• 制造差错和差错通知的操作员的立即识别

• 所有的差错交易被移到这些悬而未决的文件当中 • 记录被维持直到交易被解决和移去

• 交易显示差错代码、录入的日期和时间以及操作员/机器

• 悬而未决文件创造管理层评价、趋势分析和补救培训的追查报告 •起源、录入、处理、检验和分发职能部门的分离 对于选择的输出交易：

• 评价被处理交易清单完整性和准确性的样本 • 评价输出报告准确性和完整性的样本

• 评价输出保留计划表的适当性和程序的遵从性 • 确认输出样本的实际分发被正确地分发

• 通过确定输出以及其它系统交易处理日志的输入，确定集成的处理 • 评价所有输入、处理输出和其它系统使用的交易 • 确认只有批准的人员才能访问敏感报告

• 对于每一个保留和程序的所有数据介质来讲，确定非现场存储的毁坏或重新安置 • 依照保留程序，确定实际的保留周期

• 证明敏感输出和处理遵从、分发和安全程序的实际的交付或者传输

• 确认在与正常的处理相关的，同持续性计划的需求一样的备份创造和完整性 介质库：

• 评价用户访问敏感实用程序；决定那种访问是适当的

• 选择被毁坏的和观测整个过程的介质样本；检验通过程序的遵从性 • 决定非现场存储的数据及数据处于传输状态时控制的适当性 • 获得最新的介质库详细目录的结果；确定准确度

• 确定保持处理器对于访问所需的介质是足够的的记录 • 评价内部和外部标记规则的旁路的控制

• 通过挑选介质的评价，测试外部和内部控制的遵从性

• 评价备份创造程序，确保在灾难事件发生时的足够充分的数据 • 确定每一个预定需求的介质库的检查 确定：

• 当生产文件由操作员直接访问时，“之前”和“之后”的文件的翻版没有被创造和维持 • 敏感的输入和输出表格（也就是说，空白支票、空白证书）没有被保护 • 日志没能成批地保持，没有处理的所有阶段的总计 • 输出报告对用户没有用：数据不相关和没有用，报告不是所要的，分发不适当，格式和频率不适当，对报告的联机访问没有被控制

• 对传输的数据没有附加的控制，包括： • 有限的传输发送/接收访问

• 发送者和接收者适当的授权和确认 • 传输的安全手段

• 传输数据的加密和适当的加解密算法 • 为保证完整而进行的传输完整性测试 • 重传的程序

• 卖主合同缺少诸如毁坏服务这样的控制

• 关于诸如火、水、电和未授权访问的环境危害的非现场的不足

12.1 物理安全

12.3 来访者的陪同

12.4 人员健康和安全

12.2 IT场地低调的外观

管理设施

满足的业务需求：

提供防止IT设备和人员受到人为或自然危害的合适的物理环境 实现路线：

有规律地评价其适当机能的合适环境和物理控制的安装 需要考虑的事项： 设施的访问 场地的确定 物理安全

检查和逐步升级

业务持续性计划和危机管理 人员的健康和安全 预防性的维护 环境威胁的保护 自动化的监控 信息规范 IT资源 效果 人员 效率 应用 保密 技术 P 完整 * 设施 P 可用 数据 遵从 可靠

IT管理层应确保保持IT运行场地的低调的外观，对IT运行场地的物理确认要受到。

应有一个适当的程序，确保一个非IT职能部门运行组的人员，如果其必须进入计算机设施领域时，需要由运行组人员陪同。来访者日志应被保持，并应被定期评价。

对于IT设施，应建立适当的物理安全和访问控制措施，包括与总的安全保持一致的信息设备的远程使用。物理安全和访问控制不应只是关注系统硬件领域，而且要关注用于连接系统各部件的配线的位置、支持服务（如电源）、备份介质以及任何其它系统运行所要求的部件。对设备的访问应到被授权而获得这种访问的人。放置在公共场所的IT资源应被适当地保护，以避免或阻止来自盗窃或故意破坏所造成的损失或毁坏。

按照适用的国际、国内、地区、州和地方的法律法规的要求，应实施并维护健康和安全实践。

评估控制：

获得了解：

12.6 不间断电源

12.5 抵御环境因素的破坏

对于关键的IT应用来讲，管理层应有规律地评估不间断电源电池和发电机的需求，保证其不受电源失效或波动的影响。如果证明是合理的，则应安装最合适的设备。

对高级和详细的控制目标进行审计：

访谈： 设施经理 安全官 风险经理 IT操作经理 IT安全经理 获得：

与设施管理、布局、安全、保卫、固定资产详细目录以及资本获得/出租相关的机构的和程序 与设施的布局、物理和逻辑的安全、保卫、访问、维护、signage、来访者、保险以及环境需求、入口和出口机制、安全报告、安全和维护 、设备的详细目录、监视程序和规章要求相关的IT和程序

那些有权访问设施和设施的楼面布局的个人的清单

关于IT资源（设备和设施）性能预期的性能、容量和服务水平协议的清单，包括行业标准 持续性计划文档的拷贝

考虑是否：

设施的位置外表不十分明显，处于最少访问区域或机构内，并且访问被在最小数量的人中 逻辑和物理访问的程序是足够的，包括雇员、卖主、设备和设施维护人员的安全访问特性文件

“钥匙”和“读卡机”管理程序和实务是足够的，包括按照最小访问所需的原理的正在进行的更新和评价

进入/离开、护送者、注册、临时需要经过、对所有的人都是适当的但特别针对敏感区域的监视摄像机方面的访问和授权是适当的

定期和正在进行的访问特性文件的评价，包括管理的评价正在发生 在安全违背事件发生时，撤回、响应和逐步升级的过程发生

安全和访问控制措施包括可移动的和/或非现场的使用的信息服务

关于未被确认的敏感区域的signage存在，并与保险、本建筑物的法规以及规章需求相一致

来访者注册、经过的分配、陪同、负责来访者的人员、记录本的评价发生，确保报到和离去的发生以及接待员对安全程序的理解

火、天气、电的预警和警报程序以及各种各样环境紧急状况水平的预期响应情节的评价正在发生

为了抵御环境因素（如，火灾、灰尘、动力、过热或过湿）的破坏，IT管理层应确保采取并维护足够的措施。应安装用于监测和控制环境的专门设备和装置。

评定遵从性：

测试：

职员认识到并理解安全和保护控制的需要

接线箱被物理地保卫，仅仅授权的人员才有可能访问，电缆尽可能地通过地下或安全的导管引入 Signage确定紧急状态的路径，在紧急情况或安全背离时做什么 在设施的其它部分的Signage或电话目录没有确定敏感位置 来访者的记录没有适当追随安全程序

要求任何访问的入或出的识别程序存在——通过观察

门、窗、电梯、码头、空气排气口和输送管以及其它入口的方法被确认

计算机房是分离的、加锁的，仅仅由操作人员和维护人员按照需要的原则进行访问 设施人员循环轮班，采取适当的渡假和休假 维护程序和工作及时性能的记录存在

来自和程序的有关第二和第三替换操作的差异被报告 由于配置、环境和设施的变化而造成的物理计划被更新

环境的和保护的监控设备和记录——楼面的下面、之上、上方、周围——被维护 危险的用品不能储藏

关于安全软件或关键管理报告的访问控制的审计痕迹存在 任何过去的紧急情况或同样的文档被追踪 访问的职员是实际的雇员

访问关键管理的完整性检查正在发生

空气条件、通风、湿度控制程序以及各种各样损失或非预先出现的极端的预期的响应情节的评价发生 安全背离报警过程的评价存在，包括：

• 报警优先顺序的定义（也就是说，从风吹门开到各点的武装投弹手） • 每一优先顺序报警的响应情节

• 内部人员及与之相对应的本地或卖主安全人员的责任 • 与本地管理当局的交互 • 最近的报警训练的评价

机构对IT职能部门内的物理访问负责，包括： • 安全和程序的开发、维护和正在进行的评价 • 与面向安全的卖主建立关系

• 与安全相关的有关技术问题方面的设施管理层的联络 • 协调机构的安全认识和培训

• 通过集中的应用和操作系统软件，协调影响逻辑访问控制的活动 • 提供安全认识和培训，不仅在IT职能部门内，而且在用户服务中 在机构的设施中，为看屏幕人员，出售机器和管理人的服务实践发生 安全服务合同的内容、更新和谈判发生 穿透测试的程序和结果 • 协调物理穿透测试的情节

• 与卖主和本地管理当局协调物理穿透测试 健康、保护和环境的规章正在被遵从

物理安全在持续性计划中被说明并确保供应商设备类似的物理安全 实施安全所必须的可选择的基础设施项的具体存在： • 不间断电源（UPS）

• 可选择的或重新选择路径的电信线路 • 可选择的水、煤气、空调、湿度资源

控制的IT过程： 管理操作

13 管理操作（DS13）

证实没有满足业务目标的风险：

物理防护教育和认识是案例

与安全事件、丢失的业务和恢复设施的花费相关联保险的范围和花费的专家意见存在 执行关键和逻辑过程控制的访问变更的过程正在进行并广为人知 环境满足规章或法令的要求

报警维护日志不能被不适当地改变

访问代码变化的频率和特性文件评价——用户和所涉及设施——被形成文档

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的设施管理的基准 将物理布局与建筑物的制图和安全装置进行比较 判定下述：

• 设施本身没有出现在系统服务的位置，也没有通过方向指引、设置许多符号等等间接建议位置 • 门的数量由本地建筑物/保险的代码所

• 设施的位置由足够的物理障碍所保护，以避免车辆和人员的不适当的访问 • 交通的模式，以确保流量不会引导人员到安全区域 • 电视监控和磁带的评价是充分的

• 计算机设备的空间对访问、散热和维护是适当的

• 对于紧急状态下的水或者外来的元素，足够的设备盖子是可能的 • 来自维护日志的报警工作以及最后的报警训练报告被评价

关于温度、湿度和电的测试——升起楼面的上面和下面；假如反常发生，导致的调查研究/解决活动是什么

所有的锁和铰链（铰链内部房间）的检查

没有标记地草率处理，决定是否制造了同样缺乏的质询 当来访者护送通过设施时，看守/接待员覆盖范围的评价 设施的安全穿透测试 确定：

signage、灭火器、洒水器、UPS、排水、部线、可使用性和有规律地维护的充足性 对于窗户：确保外部看不见资源，在数据中心也没有“展示案例”的窗口 安全穿透测试判定

来访者测试，包括注册、标记、陪同、局部检查、放行 在来访者记入到来访者标记方面的差异

访问特性文件以及建立在关键管理报告基础之上的历史，包括丢失标志/关键卡的替代和使丢失条款不活动的评估

本地灾难统计的评价 开发灾难穿透情节

看屏幕人员以及遵从健康和保护需求的卖主合同发生

测试UPS，检验结果满足支持关键数据处理活动的容量和操作需求

访问信息（日志、磁带、记录）的测试由用户和管理层对其适当性进行评价 设施入口附近区域监控程序的测试

13.3 工作的时间安排

13.4标准工作时间安排的违背

13.2 启动过程和其它操作文档

13.1 处理操作程序和指导手册

满足的业务需求：

确保重要的IT支持功能被有规律、有秩序地完成 实现路线：

记录和清除所有活动完成情况的支持活动的时间安排 需要考虑的事项： 操作程序手册 启动过程文档 网络服务管理

工作量和人员时间安排 换班交接过程 系统事件日志

与变更、可用性、业务持续性管理的协调 预防性的维护 服务水平协议 自动化的操作

事件的登记、跟踪和逐步升级 信息规范 IT资源 P 效果 * 人员 P 效率 * 应用 保密 技术 S 完整 * 设施 S 可用 * 数据 遵从 可靠

对于IT操作（包括网络操作）来讲，IT管理层应建立并归档标准的程序。在场的所有IT解决方案和平台都应当使用这些程序来操作，应对该程序进行定期评价，以确保其有效性和被遵从性。

通过归档、定期地测试以及根据需要进行调整，IT管理层应确保操作人员对启动程序和其它操作任务足够的熟悉和自信。

IT管理层应确保工作、过程和任务的持续性时间安排被机构成最有效顺序，最大化吞吐量和利用率，以达到服务水平协议上的目标。最初的时间安排以及这些时间安排的变更，应被适当地授权。

应存在一个程序，来确认、调查、审批与标准工作时间安排的背离

评估控制：

获得了解：

13.8 远程操作

13.6 操作日志

13.5 处理的连续性

13.7 保护特殊的表格和输出设备

对高级和详细的控制目标进行审计：

操作人员更换期间，通过规定活动、状态更新和有关当前责任报告的正式移交，建立一个处理连续性的程序。

管理控制应确保足够的按照时间排列的信息存储于操作日志中，以使重新建立、评价和处理的时间序列检查以及其它的有关周边或支持处理活动成为可能。

管理层应针对特殊的表格，诸如可转让价值工具，以及敏感的输出设备，诸如签名卡座，建立一个适当的物理保护机制，考虑适当的会计账目来核算IT资源、表格或其它需要附加保护和库存管理的项目。

访谈：

IT操作管理层

IT持续性计划编制管理层 IT高级管理层

挑选的IT资源的用户

挑选的提供软件或硬件合同服务或产品的卖主 获得：

与操作管理和信息系统在完成业务目标的角色相关的机构的和程序

与操作角色、性能预期、工作时间安排、服务水平协议、操作员规程、人员的轮换、持续性计划和远程设施操作相关的IT和程序

启动、关机、工作负载计划安排、标准、服务水平协议、紧急状况的修理程序、异常处理的响应、控制台的日志、物理和逻辑的安全、开发和生产库的分离、问题逐步升级程序的常规功能的操作规程

关键应用，包括时间表、输入、处理时间、差错信息、异常终止规程、重新启动、问题逐步升级程序、之前和之后的工作、非现场的文件的操作规程的挑选样本

考虑是否：

具有下列证据：

• 所有被执行的处理、冷启动和重新启动以及恢复的完整性

对于远程操作，应建立特别的程序，确保对远程站点链路的连接和断开的定义和执行。

评定遵从性：

证实没有满足业务目标的风险：

测试：

操作班子成员知道并理解： • 他们所负责的操作程序

• 设施之内的性能预期——卖主的规格、机构的标准以及与用户签定的服务水平协议 • 紧急状态下程序的修理，与重新启动/恢复程序一起 • 操作日志要求和管理评价 • 问题逐步升级程序

• 轮班变化的沟通和中间轮班的责任 • 将开发程序移动到生产中的周转程序 • 与远程处理设施和中心处理设施的交互 • 向管理层沟通生产力改进机遇的责任

执行：

确定使用的适当性的操作性能统计的评价，与类似的机构、卖主的规格、适当的国际标准和可比较的行业的基准/最好实践进行比较

有的IT操作手册的样本的评价，决定它们是否满足和程序需求

启动和关闭过程的文档和经历的检查，确定这些程序以有规律原则被测试和更新 处理时间表的检查，确保依照时间表性能的适当性和充分性 确定：

挑选出来的用户，确定与正在进行的活动和服务水平协议相关的操作性能的充足性 工作异常终止（ABENDS）的样本，并决定发生问题的解决 操作员培训、轮班循环、渡假/休假的经历

准确的控制台样本，在性能和问题解决的管理评价方面的趋势——如果适用，评估问题的逐步升级 决定服务水平协议承担义务满意度的用户

关于所有设备的每一个卖主建议，正被完成的预防性的维护程序

• 初始程序装载（IPL）和关机程序的充分性

• 时间表完成的统计，以确定所有要求的成功完成

• 源代码和目标代码、测试/开发/生产库以及在这些库之间移动程序的变更控制程序的物理和逻辑的分离

• 操作活动的性能统计，包括但不限于此： • 硬件和外围设备的容量、利用率和性能 • 存储器的利用率和性能 • 电信的利用率和性能

• 性能与产品性能规格、内部定义的性能标准以及用户服务水平协议承担的义务相匹配的程度 • 操作日志在进行的基础上被维护、保持并评价 • 对所有的设备都要以及时的方式执行维护

• 操作员要循环轮班，采取渡假和休假并维护资格

1.2 评估绩效

监控

1.1 采集监控数据

1.3 评估客户的满意度

1 监控处理过程（M1）

控制的IT过程： 监控处理过程 满足的业务需求：

确保设定在IT处理程序中的绩效目标的实现 实现路线：

相关绩效指标、系统和及时的绩效报告以及背离时提示的定义 需要考虑的事项：

绩效驱动和成果测量的记分卡 客户满意度的评估 管理报告

历史绩效的知识库 外部基准 信息规范 IT资源 P 效果 * 人员 P 效率 * 应用 S 保密 * 技术 S 完整 * 设施 S 可用 * 数据 S 遵从 S 可靠

管理层应对IT职能部门所提供的服务进行测量（关键绩效指标和（或）关键成功因素），而且要与目标水平比较。IT职能的评估应持续进行。

对IT和内部控制程序来讲，管理层应确保来自内部和外部两方面的相关绩效指标（例如基准）不断地加以定义，而且要为创建这些指标相关的管理信息报告和例外报告而进行数据的采集。控制也应以确认机构和个体的绩效测量标准以及指标两者的适当性和完整性为目标。

管理层应在定常的周期下，测量由IT职能部门所提供服务的客户满意度，以确认服务水平中的不足，并建立改进目标。

评估控制：

获得了解：

1.4 管理报告

对高级和详细的控制目标进行审计：

考虑是否：

确定监控IT资源的数据是适当的

关键绩效指标和/或关键成功因素依照目标水平被用于测量IT的绩效 IT资源使用（人员、设施、应用、技术和数据）的内部报告是适当的 IT资源绩效报告的管理评价存在

监控控制存在，以便以及时的方式提供可靠的和有用的反馈 机构对质量控制、内部审计和外部审计改进建议的响应是适当的 目标绩效改进首创精神和结果存在

依照机构之内所有组的已阐明目的的机构绩效正在发生 用户满意度分析存在

为非用户，诸如外部审计师、审计委员会和整个机构的高级管理层使用的绩效报告的可靠性和可用性是充分的

报告的及时性允许迅速响应所确定的绩效短处或例外 依照已经为绩效活动而建立的和程序的报告；（也就是说绩效报告）是充分的

管理报告应该提供机构向着既定目标前进的高级管理层评价。状况报告应包括：已经达到的既定目标的程度、获得的交付、已达到的绩效目标和被减轻的风险。应根据评价结果，启动并控制适当的管理行动。

访谈：

首席执行官（CEO） 首席信息官（CIO）

高级内部审计官（SIAO） IT高级和质量控制管理层 外部审计高级经理 挑选的IT资源的用户

如果适用，审计委员会成员 获得：

与绩效方面的计划、管理、监控和报告相关的机构范围内的和程序

与绩效的监控和报告、建立绩效改进首创精神以及评价的频率相关的IT和程序

IT活动的报告，包括但不限于此：内部的报告、内部审计报告、外部审计报告、用户报告、用户满意度调查、系统开发计划和状态报告、审计委员会会议记录以及任何其它机构的IT资源使用的评估

信息服务功能计划文档以及依照这些计划的每一个资源组的交付物和实际绩效

评定遵从性：

证实没有满足业务目标的风险：

测试：

数据绩效监控的报告存在

绩效监控报告和纠正行动的首创精神的管理评价正在发生 雇员知道并理解与绩效监控相关的和程序 质量和内部报告的内容与下述相关： • 绩效监控数据的采集 • 绩效监控数据的分析 • 资源绩效数据的分析

• 绩效问题之上的管理行动 • 用户满意度调查的分析

高级管理层对绩效监控方面的报告感到满意

2 评估内部控制的适当性（M2）

控制的IT过程：

评估内部控制的适当性 满足的业务需求：

确保设置于IT程序中的内部控制目标的实现 实现路线：

承担监控内部控制的义务，评估它们的有效性，并有规律地对其报告 需要考虑的事项： 内部控制的职责

正在进行的内部控制的监控 基准

差错和例外报告 自我评估 管理报告

遵从法律法规要求 信息规范 IT资源 P 效果 * 人员 P 效率 * 应用 S 保密 * 技术

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的绩效监控的基准 正被监控的过程之内的数据关联性的评价 在所有的IT领域被计划的绩效评价的实际情况 所有的IT领域的预期的用户满意度的实际情况 绩效目的改进首创精神的完成程度的分析 管理建议实施水平的分析 确定：

信息系统机构之内的监控班子的能力、授权和性

S 完整 S 可用 P 遵从 S 可靠

获得了解：

2.1 内部控制监控

2.3 内部控制水平报告

2.2内部控制的及时操作

* 设施 * 数据

2.4 操作安全以及内部控制保证

对内部控制的信赖要求控制操作能够立即把错误和不一致突出出来，并在它们影响到产品和交付之前纠正过来。有关错误、不一致和例外的信息应被保存，并系统性地报告给管理层。

随着以检查安全和内部控制的操作是否按照规定或暗示的安全及内部控制的要求而运行的自我评估或审计的发展，应建立操作安全和内部控制保证，并要进行周期性地重复。由管理层正在进行的监控活动应寻找弱点和安全问题。

对高级和详细的控制目标进行审计：

访谈：

首席信息官（CIO）

高级内部审计官（SIAO） IT高级和质量控制管理层 外部审计高级经理 挑选的IT资源的用户

如果适用，审计委员会成员 获得：

与内部控制的计划、管理、监控和报告相关的机构范围的和程序 与内部控制和评价频率的监控和报告相关的IT和程序

IT活动的报告，包括但不限于此：内部报告、内部审计报告、外部审计报告、用户报告、系统开发计划和状态报告、审计委员会会议记录以及IT内部控制的其它评估

与操作安全和内部控制保证相关的特定IT和程序

管理层应向受影响的各方报告内部控制水平和例外方面的信息，确保其内部控制系统的持续有效性。应采取行动，以确认在决策制定的特定层次上需要什么样的信息。

在常规的操作进程中，管理层应通过管理和监管活动、比较、勾对以及其它日常行动，监控内部控制的有效性。内部控制的背离应引起分析和纠正行动。另外，这种背离应与对此职能负责的个人进行沟通，并在这个人以上至少一个管理层进行沟通。严重的背离应报告给高级管理层。

性

评估控制：

评定遵从性：

证实没有满足业务目标的风险：

测试：

内部控制监控报告存在

内部控制报告和纠正行动的首创精神的管理评价正在发生 雇员知道并理解与内部控制监控相关的和程序 内部报告的质量和内容与下述有关： • 内部控制监控数据的采集 • 内部控制遵从绩效

• 内部控制问题方面的管理行动 • 操作安全和内部控制保证

高级管理层对安全和内部控制监控方面的报告感到满意

考虑是否：

确定用于监控IT内部控制的数据是适当的 IT内部控制数据的内部报告是足够的 IT内部控制的管理评价存在

监控控制存在，以便以及时的方式提供可靠和有用的反馈

质量控制、内部审计和外部审计改进建议的机构响应是适当的 对准内部控制改进首创精神和结果存在

依照已经阐明的内部控制目的的机构的绩效正在发生

关于内部控制的差错、不一致和例外的信息被系统地保持并报告给管理层

非用户的，诸如外部审计师、整个机构的审计委员会和高级管理层的内部控制报告的可靠性和可用性是充分的

允许迅速响应已经确定的内部控制短处或例外的报告的及时性

依照已经建立活动绩效（也就是说内部控制报告）的和程序的内部控制报告是充分的

在所有IT领域的已计划的内部控制评价的实际情况 内部控制目的改进首创精神完成的程度分析 审计委员会对内部控制报告满意度的评价 管理建议实施水平的分析 确定：

内部审计报告与IT审计、管理、外部审计师和规章忧虑一致的可能的附加领域 信息系统机构之内内部控制评价班子的能力、权利和性

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的内部控制评估的基准 正被监控的过程之内以及内部控制报告中的数据的关联评价 全部机构和IT的内部控制评价框架，明确地确保覆盖范围以及过程所有者详细的各种不同级别的充足

3.3 IT服务的有效性评估

3 获得的保证（M3）

控制的IT过程： 获得的保证 满足的业务需求：

增加机构、客户和第三方提供者之间的信心和信任 实现路线：

按有规律的间隔进行的保证评价 需要考虑的事项： 的证明和鉴定 的有效性评估

遵从法律法规要求的保证 遵守合同承诺事项的保证

第三方服务提供者的评价与确定基准点 由有资格的人执行的保证评价 前移的审计介入 信息规范 IT资源 P 效果 * 人员 P 效率 * 应用 S 保密 * 技术 S 完整 * 设施 S 可用 * 数据 P 遵从 S 可靠

管理层应在日常周期性工作中获得对IT服务的有效性的评估。

3.4 对第三方服务提供者的有效性评估

3.1 IT服务的安全及内部控制的证明/鉴定

3.2 对第三方服务提供者的安全及内部控制的证明/鉴定

在实施关键的新的IT服务，以及实施之后日常周期性服务进行再证明/再鉴定之前，管理层应获得安全和内部控制的证明/鉴定。

在使用IT服务提供者以及日常周期性工作进行再证明和再鉴定之前，管理层应获得安全和内部控制的证明/鉴定。

管理层应在日常周期性工作中获得对IT服务提供者的有效性的评估。

评估控制：

获得了解：

3.8 前移的审计介入

3.7 保证职能的能力

对高级和详细的控制目标进行审计：

管理层应确保保证职能部门拥有执行诸如有效性、效率性、经济性评价所必须的技术能力、技巧和知识。

访谈：

首席执行官（CEO） 首席信息官（CIO） IT高级管理层

高级内部审计官（SIAO） 外部审计师高级经理 保证高级经理 获得：

机构范围内的组织机构图以及和程序手册 与保证过程相关的和程序 IT服务提供者合同/服务水平协议 相关的法律和规章要求和合同委托

保证的宪章/合同、预算、早期报告以及绩效历史 保证班子的经历和继续教育记录 早期的审计报告

3.5 遵从法律和法规要求以及合同承诺的保证

IT管理层应寻求在最终确定IT服务解决方案之前的审计前移介入。

管理层应在日常周期性工作中获得IT职能部门遵从法律和法规要求以及合同承诺的保证。

3.6 第三方服务提供者遵从法律和法规要求以及合同承诺的保证

考虑是否：

的保证宪章/合同被适当地建立/执行，确保足够的评价的覆盖范围（例如，认证/鉴定合格、效果评估和遵从评估）

管理层应在日常周期性工作中获得遵从法律和法规要求以及合同承诺的第三方服务提供者的保证。

的

评定遵从性：

证实没有满足业务目标的风险：

先于执行关键的新的IT服务，的认证/鉴定合格被获得

实施之后，在日常的周期中，IT服务的的重新认证/重新鉴定合格被获得 先于使用IT服务的提供者，的认证/鉴定合格被获得 在日常的周期中，的重新认证/重新鉴定合格被获得 在日常的周期中，IT服务的效果的评估被获得

在日常的周期中，IT服务提供者的效果的评估被获得

在日常的周期中，IT遵从法律和规章要求以及合同委托的评价被获得

在日常的周期中，第三方服务提供者遵从法律和规章要求以及合同委托的评价被获得 保证班子是有能力的，并正在执行每一个适当的专业标准 专业的继续教育程序帮助提供保证班子的技术能力

先于最终的IT服务解决方案，管理层要前摄地寻求审计的介入

先于使用IT服务的提供者，的认证/鉴定合格是全面、完全和及时的

在日常周期中，的重新认证/重新鉴定合格被执行，并且是全面、完全和及时的 在日常周期中，IT服务的效果的评估被执行，并且是全面、完全和及时的

在日常周期中，IT服务提供者的效果的评估被执行，并且是全面、完全和及时的

在日常周期中，IT遵从法律和规章要求以及合同委托的评价被执行，并且是全面、完全和及时的 在日常周期中，第三方服务提供者遵从法律和规章要求以及合同委托的评价被执行，并且是全面、完全和及时的

保证功能报告与发现、结论和建议相关

保证职能持有执行胜任工作所必须的技能和知识 先于最终的IT服务解决方案，前摄的介入正在发生

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的保证实体评价活动的基准 下述详细的评价：

• 依照执行的评价活动，检验保证的宪章/合同 • 决定认证/鉴定合格的适当性和及时性

• 决定重新认证/重新鉴定合格的适当性和及时性 • 决定效果评估的适当性和及时性

• 决定法律和规章要求以及合同委托的遵从评价的适当性和及时性 • 检验保证职能班子的能力 • 检验前摄审计介入 确定：

通过保证评价活动而增加的价值

依照的保证计划和预算，计划绩效的实际情况 前摄审计介入的程度和及时性

测试：

高级管理层通过保证实体的绩效

先于关键的新的IT服务的实施，的认证/鉴定合格是全面、完全和及时的

实施之后，在日常周期中，IT服务的重新认证/重新鉴定合格被执行，并且是全面、完全和及时

控制的IT过程： 提供的审计 满足的业务需求：

增加信心并从最好的实践建议中得到收益 实现路线：

在有规律的时间间隔中，进行的审计 需要考虑的事项： 审计的性 前移的审计介入

由有资格的人执行审计 审计发现和建议的清理 后续行动

审计建议的影响评估（成本、收益及风险） 信息规范 IT资源 P 效果 * 人员 P 效率 * 应用 S 保密 * 技术 S 完整 * 设施 S 可用 * 数据 P 遵从 S 可靠

4.4 能力

4.2 性

4.1 审计章程

4.3 职业道德规范与标准

4 提供的审计（M4）

审计师应与审计对象在态度和外在表现（实际与感觉）上保持。审计师不应附属于被审计的部分或部门，并且，应尽可能于机构自身。因此，审计职能部门要充分地于被审计领域，以允许审计目标的完成。

管理层应确保负有机构IT活动评价责任的审计师具有技术胜任能力，并且普遍拥有执行诸如效果、效率和经济评价所必须的技巧和知识（如CISA领域）。管理层应确保分配信息系统审计任务的审计人员，通

应由机构的高级管理层为审计职能部门建立章程。这个文档应勾画出审计职能部门的责任、权力和义务。这个章程应被定期评价，以确保维护审计职能部门的、权威和责任。

在所有所做工作当中，审计职能部门应确保遵守适用的职业道德规范（如《信息系统审计与控制协会的职业道德规范准则》）和审计标准（如《信息系统审计与控制协会的信息系统审计标准》）。适当的职业审慎应运用于审计工作的所有方面，包括遵守适用的审计和IT标准。

4.7 报告

过适当的专业继续教育，维持他们的技术能力。

获得了解：

4.8 后续行动

4.5 计划编制

4.6 审计工作的执行

对高级和详细的控制目标进行审计：

审计意见的解决依靠管理层。审计师应请求并评估有关先前的发现、结论和建议方面的适当信息，以决定是否以及时的方式执行合适的行动。

高级管理层应建立一个计划，针对安全和内部控制程序的效果、效率和经济性，以及控制IT职能部门活动的管理层能力，确保获得有规律和的审计。高级管理层应决定计划内获得审计项目的优先顺序。审计师应计划信息系统审计工作，以实现审计目标，并遵从适用的专业审计标准。

机构的审计职能部门应提供一种报告，以一种适当的格式，报告给有意接受者关于审计工作的完成情况。审计报告应声明审计的范围和目标、覆盖的期间和审计工作执行的种类和范围。报告应确定机构、有意接受者和任何环节的。审计报告也应陈述执行审计工作的发现、结论和建议以及审计师关于审计的任何保留或者限定。

审计应被适当地监督，以便为审计目标的实现以及发现适用的专业审计标准提供保障。审计师应确保他们获得了足够、可靠、相关和有用的证据，以有效地达到审计目标。审计发现和结论由这种证据的适当分析和阐述所支持。

访谈：

首席执行官（CEO） 首席信息官（CIO）

高级内部审计官（SIAO） IT高级和质量控制管理层 外部审计师高级经理

如果适用，审计委员会成员 获得：

机构范围内的组织机构图以及和程序手册 机构范围内的行为规范

与审计过程相关的和程序

先于报告和审计计划，审计的宪章、使命声名、、程序和标准 外部审计的主张、评价和审计计划

内部审计班子的经历和继续教育的记录

评估控制：

审计风险评估、预算和绩效历史 如果适用，审计委员会的会议记录

评定遵从性：

证实没有满足业务目标的风险：

测试：

高级管理层通过正在进行的审计职能部门的绩效 高级管理层的看法与审计宪章一致 内部审计要以专业标准为基准

审计师的分配要保证性和足够的技能

审计班子的专业身份证明方面的正在进行的改进正在发生 审计报告的内容与有关建议相关 概括实施及时性的追踪报告存在

考虑是否：

审计委员会被适当地建立，如果适用，有规律地开会 内部审计或机构被适当地建立 外部审计要为审计计划的完成出力

遵守适用的职业行为规范的审计是足够的

审计计划以风险评估方法和该计划的全部充足性为基础 审计被适当地计划并监督

证据是足够的充分，以支持发现和结论

职业继续教育程序在提供审计师的技术能力方面提供帮助 审计班子是能够胜任的，并在执行每一个专业审计标准 给管理层的审计发现的适当的报告过程存在 所有控制问题的追踪正在以及时的方式发生

审计覆盖范围包括信息系统审计的全部范围（也就是说，全面和应用的控制、系统开发生命周期、交易价格、经济、效率、效果前摄审计途径，等等）

执行：

依照类似的机构或者适当的国际标准/公认的行业最好实践的审计职能的基准 对下述进行详细的评价：

• 检验描绘周期性的和正在进行的评价的审计计划 • 审计正在为业务和IT计划的成功出力 • 审计职能的证据支持结论和建议

• 审计发现被交流，机遇被利用或风险被减少 • 审计建议被实施的同时利益被实现 确定：

审计建议的成本/效益

依照审计计划和预算，计划绩效的实际情况 外部和内部审计之间集成的程度