ISO/IEC 20000-1:2018条款地图、术语与转版易漏点

简介：面向信息技术服务管理体系从业者、内审员与认证审核人员的ISO/IEC 20000-1:2018中文版标准文档，适合用于标准条文查阅、体系转版对照和审核准备。文件为北京中大华远认证中心翻译的参考译本，正文按范围、规范性引用文件、术语和定义、组织背景、领导力、规划、支持、运行、绩效评估与改进等章节展开，并保留服务组合、关系与协议、供需、设计构建转换、解决与履行等过程条款，便于快速定位条款、理解新版相对2011版的结构调整。压缩包仅含1个PDF，约551KB，体积轻便，适合在电脑或移动端随时翻阅。该文档已有4376人学习下载，可作为组织建立、实施、维护和持续改进服务管理体系的条文依据，也能帮助读者梳理审核要点、对照差距并完善文件化信息与知识管理。

1. 服务管理体系的一张地图：20000-1:2018 把组织切成哪十块

不少人第一次翻开这份中文版，会觉得它“薄得不像标准”——二十多页正文，条款 8 里翻半天也找不到“事件管理到底几步走”。这个反差恰好说明了它的定位：它是一份信息技术服务管理体系（SMS）的要求文件，只写“必须达到什么”，把“怎么达到”原封不动留给组织。整份标准的地图其实极好记：条款 4 组织的背景、5 领导力、6 规划、7 支持、8 运行、9 绩效评估、10 改进。前四章打地基，第 8 章是主体（服务组合、关系和协议、供需、设计构建转换、解决与履行、服务保证六块），后两章收口。第三版 2018 年 9 月发布，取消并替代 2011 年的第二版，条款结构和术语都动过刀，拿旧版记忆去复习，最容易在细节上翻车。

2. 高阶结构骨架：条款 4～10 与附件 SL 的对应关系

2.1 条款顺序来自通用高阶结构，而不是服务流程顺序

第二版的组织方式更像“服务生命周期”，第三版换成了管理体系标准的通用骨架。标准引言里说得很直白：条款结构、3.1 的术语以及多项要求都来自 ISO/IEC 导则第一部分的补充规定附件 SL，也就是管理体系标准的通用高阶结构（HLS）。这样做的直接好处是能和其他体系整合——服务管理体系可以和基于 ISO 9001 的质量体系、基于 ISO/IEC 27001 的信息安全体系放在一套文件里跑。

所以复习时不要拿“服务战略—服务设计—服务转换—服务运营—持续改进”这条老链条往第 4～10 章上套，会错位。正确的读法是：4 定范围、5 定人、6 定目标、7 定资源、8 干活、9 看数、10 改错。重点在这：条款 8 之前的每一章都是“为第 8 章服务”的，如果复习时把 4～7 章当背景略过，到第 8 章会发现很多要求找不到落脚点，比如 8.2 的服务组合要跟 6.2 的服务管理目标对齐，8.7 的信息安全管理要跟 7.5 的成文信息对齐。

还有一个常被忽略的改动：前言 i) 明确写了，本次更新删除了原来的图 1 和对 PDCA 的引用，因为附件 SL 没有特别使用它，而且很多改进方法都能和管理体系标准一起用。这意味着“PDCA 循环图”不再是复习抓手，别再拿它当记忆锚点。

2.2 1.2 应用：能借力的条款和绝对不能借力的条款

1.2 是整份标准里最容易被读快、也最容易被判不符合的一条。它把“外包”这件事划成了三段：

举例说，把基础设施组件或服务台运行（包括事件管理流程）交给外部方，本身不违规，但组织要拿得出“对涉及服务生命周期各方的管控”的证据。重点在这：这条要求同时锁死了两件事——责任主体不能转移，管控动作必须留痕。梳理下来会发现，很多体系文件写得漂漂亮亮，一到这一条就只剩一句“已委托某外部方负责”，既没有 8.2.3 的管控证据，也说不清剩余责任边界。

2.3 第 7 章支持：六项里“知识”是新面孔

第 7 章支持有六个子条款：7.1 资源、7.2 能力、7.3 意识、7.4 沟通、7.5 文件化信息、7.6 知识。前五项在管理体系标准里属于常客，7.6 知识是第三版新增的内容之一，前言 d) 专门点了“增加了关于知识的要求和规划服务”。

把 7.6 和 3.1.6 成文信息放在一起看，关系就清楚了：成文信息管的是“控制并维护的信息及其载体”，知识管的是“组织需要哪些知识、怎么获取、怎么保持可用”。两者的分界线在于——写下来并被控制的是成文信息，留在人脑和协作习惯里、但必须有获取途径的是知识。复习时如果只背“7.6 知识”四个字，很容易在案例题里答不到“如何确定所需知识、如何保持和获取”这个层面。

同时，7.5 的成文信息在第三版里是做减法的，前言 h) 列得很清楚：

• 删除容量管理计划文件的要求，替换为容量计划的要求；
• 删除可用性计划文件的要求，替换为服务可用性要求和目标的文件；
• 删除配置管理数据库要求，替换为配置信息要求；
• 删除发布策略要求，替换为定义发布类型和频率的要求；
• 取消持续改进策略的要求，用确立改进机会的评估标准取代。

这五条是全篇最值得单独抄一页纸的内容。“最小化保留成文信息的要求，只保留关键的成文信息，如服务管理计划”是总原则，那么复习时的正确姿势是：把“必须有的文件”和“必须有但形式自由的内容”分开记。

2.4 条款 2 是空的，但引用并没有消失

第 2 章规范性引用文件只有一句：本标准中没有规范性引用文件。第一次看到会以为印刷缺页，其实它是个精确的表述——本标准正文不依赖其他标准的条文才能成立。

但引用并没有真的消失，只是换了个身份。术语条目里到处是来源标注：3.2.6 信息安全、3.2.7 信息安全事件标注来源 ISO/IEC 27000:2018；3.2.11 程序、3.2.12 记录标注来源 ISO 9000:2015；3.2.1 资产标注来源 ISO/IEC 19770-5:2015。这些属于定义溯源，不是规范性引用。重点在这：复习术语时顺着这些来源标注看，能省掉大量猜定义的时间——信息安全就是机密性、完整性、可用性三要素，和 27000 完全对齐，不需要另起一套理解。

3. 术语两套账：3.1 管理体系词表与 3.2 服务管理词表怎么对上

3.1 拆成两本术语表的用意

第三版把术语与定义拆成 3.1 管理体系标准专用术语和 3.2 服务管理专用术语两个子条款，前言 g) 说明了原因：一是基于附件 SL 增加了一些新术语，比如目标、方针；二是服务管理本身需要一套自己的词，比如资产、用户。

拆分的实际效果是：3.1 那批词（审核、能力、符合、持续改进、纠正措施、成文信息、有效性、相关方、管理体系、测量、监视、不符合、目标、组织、外包、绩效、方针、过程、要求、风险、最高管理者）负责“体系语言”，3.2 那批词（资产、配置项、客户、外部供应商、事件、信息安全、内部供应商、已知错误、问题、程序、记录、发布、变更请求、服务、服务可用性、服务目录、服务组件、服务连续性、服务级别协议、服务级别目标、服务管理、服务管理体系、服务提供者）负责“业务语言”。

重点在这：答题和写文件时，凡是描述“体系怎么运转”的句子用 3.1 的词，凡是描述“服务怎么交付”的句子用 3.2 的词。混着用最典型的翻车现场就是“服务提供方制定了不符合的纠正措施”——2018 版里服务提供方这个词已经不是主用词了。

3.2 四处改名带来的连锁反应

前言 g) 列了四组关键改名，这四组是复习时性价比最高的记忆点：

这五处看着是文字游戏，落到条款上就不一样了。比如 8.3 关系和协议里的供应商管理，管的是 3.2.4 外部供方——与组织签订合同、参与规划、设计、转换、交付或改进服务、服务组件或过程的组织外方，注 1 还特别说明“包括指定的主要供方，但不包括其分包供方”。而 3.2.8 内部供方指的是大型组织中 SMS 范围之外、签有成文协议的那一部分，比如采购、基础设施、财务、人力资源、设备等部门。一个是合同关系，一个是同一大型组织内的成文协议关系，管控方式完全不同。重点在这：把这两类供方混成一锅，8.3 的供应商管理就会漏掉内部供方那一半。

3.3 五组最容易混的术语对照

资产和配置项的关系，标准写得很清楚：资产可以是配置项，但某些配置项可能不是资产。反过来，有些资产（比如声誉、协议）根本不进配置管理。这条在 8.2 的服务组合里会直接考到——配置信息要覆盖什么范围，取决于“需要加以控制以提供服务”这个判据，而不是“值多少钱”。

再补两组：服务与服务组件。3.2.15 说服务是“通过帮助客户达成其期望的结果而向客户交付价值的手段”，3.2.18 说服务组件是“服务的一部分，与其他元素组合提供完整的服务”，例子包括基础设施、应用程序、文档、许可证、信息、资源或支持性服务。3.2.20 的 SLA 是组织与客户之间定义服务及达成一致服务指标的成文协议，注 1 明确“组织与外部供方、内部供方或作为供方的客户之间也可以建立服务级别协议”；3.2.21 的服务级别目标则是组织承诺的服务的具体可测量的特性。前者是协议，后者是协议里的数字，写文件时把这两者当同义词替换，是很常见的低级错误。

3.4 记不住时用定义关键词反推

术语条目背不下来是常态，比较省力的办法是记每个定义里的“动词+对象”，做题时反推。持续改进是“提高绩效的循环活动”，所以它一定指向绩效，不是指向“多开几次会”；不符合是“未满足要求”，所以判不符合必须先有明确要求；风险是“不确定性的影响”，影响可正可负，所以风险不等于威胁；外包是“安排外部组织承担组织的部分职能或过程”，注 1 强调“外部组织不在管理体系覆盖范围内”——这句是判断范围题的钥匙。

提示：3.1.19 要求有一条注 3，说在 SMS 背景下，服务要求通常是达成一致并形成文件的要求，另外还包括法律法规等隐含或必须履行的要求。复习范围题时这条经常被漏。

4. 第 8 章运行拆解：六类活动与十八条流程的复习重点

4.1 第 8 章六块活动的划分逻辑

第 8 章是整份标准最厚的一章，从 31 页一直写到 46 页之前，分成六块：8.1 运营和计划和控制、8.2 服务组合、8.3 关系和协议、8.4 供需、8.5 服务设计构建和转换、8.6 解决和履行、8.7 服务保证。第三版把以前合并在一起的流程做了条款分离——前言 e) 点名了事件管理、服务请求管理、服务连续性管理、服务可用性管理、服务级别管理、服务目录管理、容量管理、需求管理。分离的直接后果是：每个流程都能单独找到对应条款，复习时可以按条清点，不用在一个大条款里翻找。

按功能给六块归个类，记忆负担会小很多：8.2 是“底账”（有哪些服务、哪些资产、哪些配置），8.3 是“关系”（跟客户、跟供方怎么约），8.4 是“钱和量”（预算核算与需求），8.5 是“改”（变更、设计转换、发布部署），8.6 是“修”（事件、请求、问题），8.7 是“保”（可用性、容量、连续性、信息安全）。

4.2 服务组合与资产配置：底账怎么建

8.2 服务组合下面挂着服务交付、服务计划、服务生命周期涉及的相关方的管控、服务目录管理、资产管理、配置管理等内容。这一块的复习重点不是背名字，而是搞清楚三本账的关系：

• 服务目录（3.2.17）：组织向其客户提供服务的成文信息，面向客户视角；
• 资产账（3.2.1）：对组织有潜在或实际价值的元素，允许包含负债和风险这类负价值项；
• 配置信息：需要加以控制以提供服务的元素的信息，第三版把原来的“配置管理数据库”要求换成了“配置信息”要求，形式自由，但内容不能少。

三本账的颗粒度天然不同：服务目录粗到“一项服务一行”，配置信息细到“一个组件一行”，资产账则要覆盖那些不进配置管理但确有价值的东西。梳理下来会发现，很多组织的配置信息只覆盖了硬件和软件，把文档、许可证、信息、支持性服务这些 3.2.18 明确列举的服务组件类型漏在外头。

8.2 里还有一项容易被略过的内容：对涉及服务生命周期各方的管控（第二版叫“由其他各方运行的流程治理”，前言 f) 说明了改名）。1.2 把责任证据指向这里，可见它是应对外部方参与的核心条款。重点在这：改名之后，管控对象从“流程”扩展到“服务、服务组件和流程”，复习时如果还按“只管外包流程”理解，会少答一半。

4.3 关系与协议：三层协议怎么分层

8.3 关系和协议包含商务关系管理、服务等级管理、供应商管理。这三者对应三种不同方向的约定：对客户是 SLA（3.2.20），对内部供方是成文协议（3.2.8），对外部供方是合同（3.2.4）。三层协议的服务级别目标（3.2.21）必须能串起来——客户侧承诺的可用性，不能高于外部供方承诺给你的可用性，否则中间那段落差就是自己扛。

一个可以直接抄去用的表达方式，是把“服务—组件—指标—证据”四层写成结构化文本。标准不规定格式，只要求成文信息可控制、可追溯，所以用什么载体都合规，关键是内容齐。

# 服务目录条目：对应 3.2.17 服务目录、8.2 服务组合中的服务目录管理 service: id: SVC-001 name: 某内部协同平台 description: 面向内部用户的文档协作与流程审批服务 customer: 某业务部门 # 3.2.3 客户：接受一项或多项服务的组织或组织的一部分 service_components: # 3.2.18 服务组件：组合起来才构成完整服务 - 应用前端 - 应用服务端 - 数据库集群 - 运行所需许可证 catalogue_status: 在用 owner: 某服务经理 # 8.2 服务组合：每项服务要有明确的责任归属

这段的作用是把“服务”和“服务组件”拆开摆在纸面上。参数说明：customer填的是 3.2.3 意义上的客户，可以是组织内部的一个部门；service_components只列组合成完整服务所必需的要素，许可证、文档这类无形要素也要写进去；owner不是装饰字段，它对应 8.2 里服务责任的可追溯性。

# 服务级别协议片段：对应 3.2.20 SLA 与 3.2.21 服务级别目标 sla: service_id: SVC-001 parties: [组织, 某业务部门] targets: - name: 服务可用性 metric: 实际可用时间 / 约定服务时间 # 3.2.16 注 1 给出的比率口径 target: ">= 99.5%" window: 每月 evidence: 可用性月报 # 9 绩效评估：监测、测量、分析和评估 - name: 事件响应 metric: 从记录到首次响应的时长 target: "<= 30 分钟" window: 服务时段内 review_cycle: 每季度

这段的重点在metric和evidence两行。指标口径必须写死，3.2.16 的注 1 明确服务可用性可表示为实际可用时间与约定时间的比率或百分比，口径不写清，“99.5%”就是个玄学数字；evidence则直接连到第 9 章，没有证据的指标在审核场上等于不存在。

4.4 供需：预算核算与需求管理不是一回事

8.4 供需包含服务的预算和核算、需求管理。这两项放在一起，是因为它们共同回答“要花多少钱、要满足多少量”。需求管理在第三版被单独拆条（前言 e) 有列），它的对象不是“收集用户想要什么”，而是服务需求与供给能力之间的匹配关系。复习时容易把它和服务级别管理混起来：服务级别管理管的是“承诺什么水平”，需求管理管的是“实际需要多少量”。

预算和核算这条，重点在于“服务的”三个字——它是按服务口径算账，而不是按部门口径。梳理下来会发现，很多组织财务上算得很细，但算不到“某一项服务一年到底花了多少”，这样 8.4 的要求就很难拿出证据。

4.5 设计构建转换与解决履行：改与修要分开

8.5 服务设计构建和转换包含变更管理、服务设计和过渡、发布和部署管理。注意发布的定义（3.2.13）：作为一项或多项变更的结果，部署到实际运行环境的服务或服务组件以及新服务的一个或多个变更的组合。也就是说变更请求（3.2.14）是提议，发布是落地组合，两者不是同义词。前言 h) 提到，原来的发布策略要求被替换为“定义发布类型和频率的要求”，这意味着不必再写一份策略文件，但必须说清楚有哪些发布类型、各自频率如何。

8.6 解决和履行包含事件管理、服务请求管理、问题管理。这一块最典型的踩坑是把事件和问题当成一个流程的两个阶段。按 3.2.5 和 3.2.10 的定义，事件是现象，问题是原因，一个事件可以没有对应问题（快速恢复即可），一个问题也可以对应零个已发生事件（潜在事件）。已知错误（3.2.9）是问题的一种状态：根因已识别，或者已找到减轻、消除影响的方法。重点在这：事件管理的目标是恢复服务，问题管理的目标是消除原因，KPI 不能共用一套。

4.6 服务保证：四条线的分工

8.7 服务保证包含服务可用性管理、容量管理、服务连续性管理、信息安全管理。四条线各管一件事：

服务连续性这条的注 1 值得单独记：服务连续性管理是业务连续性管理的一个子过程，ISO 22301 是业务连续性管理体系的标准。这句话解释了两者的从属关系，也解释了为什么连续性方案必须向上对齐业务影响分析，而不是 IT 自己拍脑袋定 RTO。

5. 转版易漏点：五个最容易被判不符合的地方

5.1 易漏点一：全外包还想声称符合

为什么漏：不少组织以为“把服务台和基础设施都交给外部方”只是运营模式选择，体系文件照旧写“本组织建立并运行服务管理体系”。但 1.2 的表述没有留余地：如果由其他方承担提供或运行 SMS 范围内所有服务、服务组件或流程的所有责任，组织不能声称符合本标准。

怎么补：先画一张责任矩阵，把每个服务、每个服务组件、每条流程的“决策责任、执行责任、证据责任”三列填满。只要出现某一列整列都是外部方，就必须调整范围或调整合同。另外，条款 4 和 5 虽然可以由其他方支持，但组织自身仍要证明符合，这两章不能借力到底。

5.2 易漏点二：把“删掉文件要求”读成“这件事不用做了”

为什么漏：前言 h) 一口气删了五项文件要求，读快了容易记成“容量管理不用做、可用性不用管、配置数据库不用建、发布策略不用写、改进策略不用定”。

怎么补：把“文件”和“内容”分开记。删除的是文件形式，保留的是内容要求——容量计划要有，服务可用性要求和目标要有文件，配置信息要有，发布类型和频率要定义，改进机会的评估标准要确立。复习时用“要求还在，载体自由”这八个字过一遍这五条，基本不会错。

5.3 易漏点三：体系文件还在用第二版的名词

为什么漏：改名这类事在正文里不显眼，但在前言 g) 里是成组出现的，而且改的恰恰是高频词——服务提供方、内部小组、供方、可用性。

怎么补：做一次全文检索，把这四个词在体系文件里的出现位置全部拉出来，逐条判断该换成组织、内部供方、外部供方还是服务可用性。特别是“可用性”这个词，在信息安全语境下必须保留，在服务语境下必须加“服务”前缀，一刀切替换会出新错。

5.4 易漏点四：事件、问题、已知错误三者的落点没分开

为什么漏：三个定义挨得很近，日常口语里又常混着说“这个事件是个问题”，导致文件里三个流程用同一套记录模板、同一套指标。

怎么补：按定义各设一条判据。事件看“是否造成或可能导致服务中断、质量下降”；问题看“是否在找原因”；已知错误看“根因是否已识别或是否有缓解方法”。三条判据对应三张不同的记录，指标也分开设：事件看恢复时长，问题看根因关闭率，已知错误看知识库命中率。

5.5 易漏点五：服务报告只在第 9 章找

为什么漏：一看到“服务报告”就直奔 9 绩效评估，忽略了前言 j) 的那句说明——服务报告的详细要求已经从服务报告条款移到服务报告可能产生的条款中。

怎么补：反向查。把 8.2 到 8.7 每一条里“需要形成成文信息”“需要报告”的表述标出来，这些就是服务报告的真实来源条款；第 9 章那边主要管监测、测量、分析和评估、内部审核、管理评审这几件事的组织方式。两条线合起来，服务报告的内容才完整。

6. 复习清单：用一张条款—证据对照表查漏补缺

复习到最后一公里，最有效的动作不是再读一遍标准，而是给自己出一张“条款—证据”对照表，逐行填。填不出来的那一行，就是你的漏洞所在。下面这张表可以照着扩到全部条款：

表填完，再用脚本自动扫一遍覆盖率，比人眼翻要稳。下面这段脚本读一份 CSV（表头为clause,evidence,owner,status），把子条款归到一级条款后检查 4～10 章有没有空档：

# 条款证据自检：检查 4~10 章每个一级条款是否都有可用证据 import csv from collections import defaultdict REQUIRED = ["4", "5", "6", "7", "8", "9", "10"] def load(path): with open(path, encoding="utf-8") as f: return list(csv.DictReader(f)) # 逐行读成字典，字段名取自表头 def check(rows): seen = defaultdict(list) for r in rows: root = r["clause"].strip().split(".")[0] # 8.3.2 -> 8，按一级条款归并 if root in REQUIRED and r["status"].strip() != "缺失": seen[root].append(r["evidence"]) for c in REQUIRED: # 空条款往往就是审核时被追问最多的地方 print(f"条款 {c}: " + (f"{len(seen[c])} 条证据" if seen[c] else "没有可用证据")) if __name__ == "__main__": check(load("clause_evidence.csv"))

参数上只有三个要点：clause允许写到三级（如 8.3.2），脚本会自动归并；status只用来标记“缺失/待补”，不参与统计；evidence写证据的名字而不是路径，逼自己用一句话说清这份材料证明了什么。跑完输出里凡是“没有可用证据”的行，直接回到对应章节重读那一条。

我自己的血泪经验是：第一遍复习时我按目录顺序从头读到尾，自我感觉良好，直到动手填这张表，才发现 8.2 的服务组合和 8.3 的关系与协议在我脑子里是糊成一团的，配置信息和资产账根本分不开。从那以后我每次复习这套标准，都强制先跑一遍这张表和这段脚本，再回去读条款——先找洞，再补墙，比顺着页码读十遍都管用。希望帮到你。

本文还有配套的精品资源，点击获取