第 3 章　信息系统治理

【为什么选 A】治理与管理的分界线是「层次」：治理在战略与方向层面，处理 IT 决策机制、责权分配与监督问责（做正确的事）；管理在执行与运营层面，运用计划、组织、领导、控制等职能把事情做好（正确地做事）。A 项完整准确地表达了这组对应关系。

【B 错在哪】该选项把两者的职责正好说反了——日常开发组织与进度控制是管理职能，审定重大投资是治理（决策层）职能，属于典型的「张冠李戴」。

【C 错在哪】治理与管理是不同层面的分工衔接，不是重复设置；治理为管理划定边界与授权，管理向治理层报告绩效，两者缺一不可。

【D 错在哪】项目实施细节属于管理范畴，组织战略层面属于治理范畴，该选项把两者的定位完全对调。

【为什么选 A】IT 治理是公司治理体系在信息化领域的延伸与组成部分，治理主体是董事会、IT 治理委员会等治理层机构，利益相关方广泛参与；其目标是推动 IT 与业务战略一致、实现业务价值并管控 IT 风险。A 项准确表述了这一性质。

【B 错在哪】把 IT 治理降格为 IT 部门内部事务，直接违背「治理在顶层、主体是治理层」的核心特征，是最常见的错误选项。

【C 错在哪】「用最先进的技术」是技术导向的思维，治理关注的是业务价值与战略一致，而非技术先进性本身；先进技术若与战略脱节恰是治理失效的表现。

【D 错在哪】风险管控只是 IT 治理目标的一翼，另一翼是价值实现（推动 IT 创造业务价值），「只关注风险」的表述以偏概全。

【为什么选 C】三层结构中，决策层（董事会及其下设的 IT 治理委员会、信息化领导小组等）的职责是确定 IT 与业务一致的战略方向、审定重大 IT 投资与重大制度、设置治理架构并监督整体绩效——「定方向、批投资」正是决策层的标志职能。

【A 错在哪】执行层由开发、运维团队构成，负责按制度与标准执行具体操作，既无决策权也无审批权。

【B 错在哪】管理层（CIO 及信息化管理职能部门）负责把治理决策转化为规划、制度与标准并组织实施，是「承上」的枢纽，但重大投资的审批权在决策层而非管理层。

【D 错在哪】承建商项目组是组织外部的交付力量，连组织内部执行层都不是，更不可能承担治理决策职能，属于身份错位的干扰项。

【为什么选 B】IT 治理的核心内容包括战略一致、组织责权、资源统筹、风险管控、绩效评价与制度流程等层面。「建立投资优先级审定机制、统筹重大资源配置」属于资源治理与责权治理，是治理层制定「规矩」的行为，符合治理的层次特征。

【A 错在哪】编制项目周计划与人员分工是典型的项目管理（管理执行层）活动，层次在具体项目之内，够不到治理层面。

【C 错在哪】更换硬盘是运维操作层面的日常执行工作，属于 IT 管理（服务运营）范畴，与治理无关。

【D 错在哪】修复界面缺陷是开发执行层面的具体作业，同样是「正确地做事」的范畴。

【为什么选 A】题干关键词「统一规划企业架构」「消除烟囱式建设」直指架构治理需求。TOGAF 是主流企业架构框架，其核心的架构开发方法（ADM）引导组织在业务、数据、应用、技术等架构领域做整体规划与演进，正是解决系统林立、重复建设的对症工具。

【B 错在哪】CMMI 是过程能力成熟度模型，用于评估和改进研发等过程能力，不提供企业架构规划方法，解决不了「系统怎么布局」的问题。

【C 错在哪】ITIL 是 IT 服务管理最佳实践框架，面向服务交付与运维流程（事件、问题、变更等），与架构统一规划无关。

【D 错在哪】COBIT 面向 IT 治理与管控，回答「决策与管控体系怎么搭」，能从治理层面问责重复建设，但不提供具体的架构开发方法，与题干需求不直接对口。

【为什么选 C】题干关键词「研发过程能力」「成熟度」直接指向 CMMI（能力成熟度模型集成）。它将过程能力划分为初始级、已管理级、已定义级、量化管理级、优化级五个等级，为组织提供评估现状、定位差距、指导改进的路径，其认证也被市场广泛认可为过程能力资质。

【A 错在哪】ITIL 面向 IT 服务与运维管理，不评估研发过程成熟度，与服务台、事件流程相关而与开发过程能力无关。

【B 错在哪】COBIT 面向治理与管控目标体系，虽然带有成熟度级别的评估能力，但其定位是治理管控而非研发过程改进，与题干需求不符。

【D 错在哪】TOGAF 是企业架构框架，解决「系统怎么布局」的问题，与过程成熟度评估不在同一范畴。

【为什么选 B】题干关键词「报障、故障处理、服务成效」指向 IT 服务管理领域。ITIL 是 IT 服务管理的事实标准，按服务生命周期（服务战略、服务设计、服务转换、服务运营、持续服务改进）组织最佳实践，服务台建设与事件、问题、变更等服务管理流程均以 ITIL 为蓝本，与题干场景完全对口。

【A 错在哪】TOGAF 解决企业架构统一规划问题，不提供服务管理的流程方法。

【C 错在哪】CMMI 面向研发过程成熟度，虽也有服务能力模型的应用方向，但题干诉求是建立规范的服务管理流程与闭环，首选 ITIL 而非 CMMI。

【D 错在哪】TOGAF 管架构、COBIT 管治理管控，两者组合依然覆盖不了「服务怎么交付、流程怎么建」的需求层面，属于框架错层的组合式干扰。

【为什么选 A】COBIT（信息及相关技术控制目标）由 ISACA 发布维护，是专门面向 IT 治理与管控的框架：它区分治理域与管理域，给出成体系的治理与管理目标，并配套成熟度级别评估，因此既是治理层搭建治理体系的设计参照，也是审计人员开展 IT 管控审计的检查依据。

【B 错在哪】ITIL 起源于英国政府部门的最佳实践总结，聚焦 IT 服务管理，不由 ISACA 发布，也不是治理管控框架。

【C 错在哪】TOGAF 由 The Open Group 制定维护，定位是企业架构开发方法，与「治理与管控目标体系」不同域。

【D 错在哪】CMMI 是能力成熟度模型集成，面向过程能力评估改进，不属于 ISACA 的治理管控框架体系。

【为什么选 A】题干主语是「董事会」，诉求是「投入价值说不清、风险看不见底」——这是典型的治理层课题。COBIT 恰好站在治理层视角，其治理过程覆盖评估、指导与监督（EDM），并以治理与管理目标体系配套成熟度评估，能同时回答「价值有没有实现」「风险是否可控」两大问题，与题干完全对口。

【B 错在哪】CMMI 评估的是研发等过程能力，反映的是「过程规不规范」，无法回答「投资值不值、风险控没控」的治理问题，层次不对。

【C 错在哪】ITIL 规范的是服务交付流程，能改善服务体验，但服务流程规范不等于治理管控到位，答非所问。

【D 错在哪】TOGAF 解决架构统一问题，架构规划是治理决策之后的落地工具之一；「先架构后治理」把顺序与层次都搞错了。

【为什么选 B】IT 审计是由独立机构和人员对信息系统及其管控活动进行的检查与评价，独立性（组织、经济、业务上独立于被审计对象）是其本质特征；审计范围覆盖信息系统的规划、建设、运营全过程，而非仅运行阶段。

【A 错在哪】开发团队自审自查违背独立性原则——自己检查自己开发与运行的对象，审计结论丧失公信力，形同虚设。

【C 错在哪】「只在上线后审计」缩小了审计范围：立项、建设、验收阶段同样存在管控问题（如投资合规性、项目规范性），均在审计覆盖之内。

【D 错在哪】审计的职能是独立评价与提出建议，整改的决策与落实是管理层的责任；审计可以「督促」但绝不「代替」，这是审计与管理的基本边界。

【为什么选 D】题干特征词「全量采集、比对分析、筛查异常」指向利用计算机辅助审计技术（CAAT）与大数据手段的数据分析法：审计人员借助工具对海量电子数据进行提取、转换、比对与筛查，从全量数据中发现人工抽样难以发现的异常模式。

【A 错在哪】访谈法是通过与人员面谈了解情况的方法，不涉及对日志数据的自动化处理，与题干手段完全不符。

【B 错在哪】观察法是到现场实地查看运作情况，日志分析是在计算机上进行的离线分析，不属观察。

【C 错在哪】文档审查法是审阅制度、纪要、变更单等书面/电子文档以核实制度与留痕，虽日志可视为证据的一种，但题干强调的是「全量比对分析」这一数据处理手段，属于数据分析法而非一般意义的文档审查。

【为什么选 A】IT 审计四个阶段的逻辑链条是：先「准备」（定目标范围、组队、制定方案、下达审计通知书），再「实施」（符合性/实质性测试、取证、编底稿），然后「报告」（汇总发现、交换意见、提交报告），最后「后续跟踪」（督促整改、验证成效）。准备在前、报告在实施之后、跟踪收尾，顺序不可颠倒。

【B 错在哪】把「实施」放到「准备」之前——没有方案与通知书就进场取证，程序颠倒。

【C 错在哪】报告先行更是逻辑混乱，无取证不报告，前两步位置均错。

【D 错在哪】报告夹在准备与实施之间——审计报告必须基于实施阶段获取的证据，此序错误。

【为什么选 C】审计报告阶段的标志性工作有三件：汇总审计发现并撰写报告、与被审计单位交换意见（沟通核实）、正式提交或公布报告。题干三个动作一一对应，故属报告阶段。

【A 错在哪】准备阶段做的是定目标范围、组建审计组、制定方案、下达通知书等前置工作，报告撰写远在其后。

【B 错在哪】实施阶段的核心是测试取证与编制工作底稿，是报告的「原料」环节而非「成文」环节。

【D 错在哪】后续跟踪阶段处理的是报告提交之后的整改落实与成效验证；「交换意见、提交报告」发生在整改之前，仍属报告阶段。这是命题人最爱互相挪位的一对边界。

【为什么选 B】机房环境、网络、操作系统、数据库等基础层面的访问控制、职责分离、备份恢复等控制统称「一般控制」——它们不针对某个具体业务应用，而是支撑所有应用系统运行的公共控制环境。对其执行情况的检查属于 IT 基础设施与一般控制审计。

【A 错在哪】应用系统审计针对具体业务应用的输入、处理、输出控制与功能正确性，题干检查对象是基础设施层面而非某个业务应用的功能与处理逻辑。

【C 错在哪】IT 项目审计检查建设项目的立项、实施、验收与投资绩效，面向「工程过程」，与运行环境的控制检查不同。

【D 错在哪】数据审计关注数据的真实性、完整性与合规使用；题干虽提及数据库，但检查的是账号权限与备份机制等控制活动，而非数据内容本身的质量。

【为什么选 A】三类问题分属三个层面：系统林立是架构层问题——用 TOGAF 统一企业架构；服务投诉与流程混乱是服务层问题——用 ITIL 建立服务台与事件、问题、变更等流程；投资管控成效无评估是治理层问题——用 COBIT 建立治理管控与评价体系。按「架构—服务—管控」对症组合引入，各框架各司其职。

【B 错在哪】CMMI 只能评估改进研发过程能力，既做不了架构规划，也建立不了服务流程与治理评价体系，「一个框架包打天下」是定位误用。

【C 错在哪】服务流程理顺只能解决投诉问题，系统不通、管控缺位依然存在，以偏概全。

【D 错在哪】「同时全面引入、一步到位」忽视组织承接能力与改进的阶段性，框架落地应分清主次、分步实施，贪大求全往往导致体系空转。