简介：面向信息安全管理人员、ISO 27001实施与咨询顾问及数据安全治理学习者，ISO/IEC 27002:2022中文版PDF围绕新版信息安全控制指南，帮助读者对照标准梳理控制目标、定制组织控制措施并理解认证落地要求。压缩包仅含1个PDF文件，约44.41MB，主体为中文试译稿v1.2，目录涵盖序、引言、背景和语境、信息安全要求、控制与确定控制、组织个性化指南、生命周期考虑因素、相关国际标准，以及范围、术语定义缩写、标准结构、主题属性和组织控制等章节。已有351人学习，适合在内审、咨询、制度编写和培训中查阅条款。借助完整目录和章节译文，读者可把握2022版变化脉络，将网络安全、数据安全治理要求映射到具体控制项，作为体系对标参考。

1. 从附录 A 到实施指南：这份 93 条控制的中文试译稿解决什么问题

做 27001 认证的团队大多遇过同一个尴尬：附录 A 把控制目标列得清清楚楚，可“具体要配什么措施、查什么证据、留什么记录”，标准本身不回答。ISO/IEC 27002:2022 补的正是这一段——它把 27002 信息安全管理体系的控制逐条铺开，给每条配上控制陈述、目的和实施指南。手头这份 v1.2 中文试译稿，按 2022 年 2 月英文原版逐章译出，覆盖第 5 到第 8 章共 93 条控制、第 3 章术语定义、第 4 章结构说明，并附附录。适合三类人：正在从零搭 ISMS 的、准备做 2013 版换版的、需要给内部讲控制落地的。读它不必先啃英文原版，但得清楚哪些地方必须回查原文。

2. 拆开 93 条控制：4 大主题与 5 类属性怎么当索引用

第一次翻开这份稿子，目录会劝退一批人——从 5.1 一路排到 8.34，编号密得像电话簿。实际上它的组织逻辑非常规整：先按主题分章，再用属性给每条控制打五个维度的标签，最后在附录里按不同视图重排一遍。搞懂这两层结构，93 条就不再是一堆平铺的条款，而是一张能按需检索的网。

2.1 四大主题的划分逻辑与 2013 版 14 域的对应关系

2022 版把控制重新归成四类：组织控制（第 5 章）、人员控制（第 6 章）、物理控制（第 7 章）、技术控制（第 8 章）。从目录逐条数下来，5.1–5.37 是 37 条，6.1–6.8 是 8 条，7.1–7.14 是 14 条，8.1–8.34 是 34 条，合计 93 条——这个数字可以直接从稿子里点出来，不用去别处找。

四主题的划分本质上是按“控制作用对象”切的：管流程和治理关系的进第 5 章，管人的进第 6 章，管空间和设备的进第 7 章，管系统和数据的进第 8 章。这个切法比 2013 版按 14 个域（安全策略、组织信息安全、人力资源安全、资产管理……）分要粗，好处是跨域引用少了，坏处是老体系里的“资产管理者”“访问控制”这类域概念被拆散到了多个主题。

提示：做换版映射时，别按编号尾号猜对应关系。旧 A.9.1.1 和新 5.15 名字都叫访问控制策略，但内容范围已经变了，逐条对读是唯一可靠的办法。

2.2 五类属性当检索维度：一张矩阵把 93 条筛成你要的那几条

稿子第 4.2 节讲“主题和属性”，这是 2022 版最实用的新增。每条控制都带五类标签，含义如下：

这五类属性的价值在于把“读标准”变成“查标准”。举个实际场景：公司刚上 SIEM，想论证还需要补哪些检测能力。做法是拉出所有“网络安全概念 = 检测”的控制，逐条看现有日志源能不能覆盖；再拉出“控制类型 = 检测性”的控制做交叉验证，两组差集就是缺口。整个过程不用通读 93 条，十分钟能出一版清单。

同一个思路反过来用也成立：安全运营团队按“运行能力”认领条款，IAM 组拿身份与访问管理那批，漏洞管理组拿威胁与漏洞管理那批，认领完再对齐，比开会分锅高效得多。

2.3 控制条目的统一版式：控制、目的、指南三段怎么读

从 4.3 节“控制的布局”能看出，2022 版每条控制都是固定骨架：控制陈述（一句话说做什么）、控制目的（说为什么做）、控制指南（说怎么做、注意什么）、其他信息（引用和补充）。四段里最容易被跳过的是“目的”，而它恰恰是审计时最常被追问的部分。

举个读法示例，5.7 威胁情报：控制陈述讲“信息安全威胁情报应与相关信息关联并保持最新”；目的是让组织建立对威胁环境的认知以支撑决策；指南里提到情报来源分级、与事件管理的联动、与供应商情报的对接。落地时，控制陈述对应制度文件的一句话原则，目的对应管理层汇报的口径，指南对应操作细则。三段各归其位，制度、汇报、SOP 三层文件就都有了出处。

读这份稿子时建议养成一个动作：每读一条，先看目的，再看指南，最后回头看陈述。目的看不明白的，多半是这条控制在你组织里没有真实场景，先放着比硬套强。

3. 从条款到台账：把 93 条控制落成可审计清单的四步

把标准读通是一回事，把它变成审核员能查、团队能干活的东西是另一回事。常见做法是 Excel 台账，但 Excel 撑到 93 条加属性矩阵就开始失控——筛不动、版本对不上、多人改就冲突。我一般会做四步：拆条目、定字段、做映射、跑差距。

3.1 第一步：按“控制—目的—指南”三段式拆条目

拆条目的核心是别把整段抄进表格。一段指南动辄几百字，抄进去后面根本没法用。正确做法是每条控制拆成三类内容：

• 控制陈述原文摘录，一句，保留标准口径，用于合规判定；
• 实施要点，三到五条，自己提炼，写清“要有什么文件、要做什么动作、要留什么证据”；
• 证据清单，列明审核时能拿出来的东西，比如策略文件编号、系统截图、日志保留周期、培训签到记录。

提炼要点时有个判断标准：如果一条要点写不出对应的证据，说明它还是空话，得往下再拆一层。比如 8.15 日志，光写“应记录事件日志”没用，要拆成“记录哪些事件类型”“日志保留多少天”“谁能读”“异常怎么告警”“时钟怎么同步（这条要引 8.17）”。拆到能指认具体系统和具体字段，才算落地。

3.2 第二步：台账字段设计与结构化落地

字段设计决定后面能不能自动筛。我用的最小字段集是：控制编号、标题、主题、控制类型、CIA 属性、网络安全概念、运行能力、安全域、现状等级、责任人、证据链接、备注。前面八个来自标准，后面四个来自组织自己。

结构化存储用 YAML 比 Excel 好维护，原因是能进 Git、能 diff、能被脚本读。示例结构如下：

# iso27002_controls.yaml —— 控制台账最小结构 controls: - id: "5.7" title: "威胁情报" theme: "组织控制" attributes: control_type: ["预防性"] cia: ["保密性", "完整性", "可用性"] cybersecurity_concepts: ["识别"] operational_capabilities: ["威胁与漏洞管理"] security_domains: ["治理与生态系统"] status: "部分实现" # 未实现 / 部分实现 / 已实现 owner: "安全运营组" evidence: ["TI-001 情报源清单", "SOC-014 情报处置记录"] note: "情报源分级待补" - id: "8.15" title: "日志" theme: "技术控制" attributes: control_type: ["检测性"] cia: ["保密性", "完整性", "可用性"] cybersecurity_concepts: ["检测"] operational_capabilities: ["事件管理", "系统与网络安全"] security_domains: ["防御"] status: "部分实现" owner: "基础架构组" evidence: ["LOG-003 日志留存策略"] note: "保留 180 天，未覆盖数据库审计"

字段里有几个点值得说明。status用三档而不是打分，是因为三档能直接对应审核结论，打分反而要在汇报时再解释一遍。owner写组不写人，人员流动时不用改台账。evidence存的是文件编号或系统里的记录 ID，不存路径——路径会变，编号不会。

有了这份 YAML，筛“检测性且属于事件管理能力”的控制就是几行代码：

import yaml from collections import defaultdict # 读台账，按网络安全概念统计控制分布，并列出缺口 with open("iso27002_controls.yaml", encoding="utf-8") as f: data = yaml.safe_load(f) by_concept = defaultdict(list) gaps = [] for c in data["controls"]: # 每条控制可挂多个概念标签，逐個展开 for tag in c["attributes"].get("cybersecurity_concepts", []): by_concept[tag].append(c["id"]) # 未实现或部分实现的记入缺口清单 if c["status"] != "已实现": gaps.append((c["id"], c["title"], c["status"], c["owner"])) for concept, ids in sorted(by_concept.items()): print(f"{concept}: {len(ids)} 条 -> {','.join(ids)}") print("\n待补齐控制：") for g in sorted(gaps, key=lambda x: x[0]): print(f" {g[0]} {g[1]} [{g[2]}] 责任组: {g[3]}")

这段脚本干两件事：按网络安全概念维度统计覆盖密度，以及列出所有未闭环的控制。attributes里的键名要和 YAML 保持一致，概念标签是列表所以用循环展开；status的判断值改成你组织自己的档位名即可。跑出来的第一段输出能直接贴进汇报材料，第二段输出就是下一季度的工作项。

3.3 第三步：映射 27001 附录 A 并写适用性声明

这里有个反复出现的误解：27002 不是认证依据。认证审核看的是 27001 附录 A 的控制目标加组织自己的适用性声明（SoA），27002 只提供“这条控制该怎么做”的参考。所以台账和 SoA 是两个东西，前者对内，后者对外。

映射的做法是给台账每条控制加一个soa_ref字段，指向 27001 附录 A 的对应条目。93 条控制与附录 A 不是严格一一对应，存在一条控制支撑多个附录 A 条目、或几条控制共同支撑一个条目的情况。映射完成后，SoA 里每条“适用/不适用”的判断理由，就能直接引用台账里的实施要点，不用另写一套话术。

不适用的条目要写清排除理由，且理由必须能站住。常见能站住的理由：业务上确实不存在该场景（比如无生产制造环节的物理周界要求）、风险已通过其他方式转移、控制由供应链承担且有合同约束。站不住的理由通常是“暂时没做”，这类写进去审核时会被追着问。

3.4 第四步：用属性矩阵做差距分析与优先级排序

差距分析最容易犯的错是平均用力——93 条全列一遍，每条都写“部分实现”，最后没人知道先补哪条。用属性矩阵可以把排序做得有依据：先看网络安全概念维度覆盖是否偏科，再看控制类型分布是否全是预防性、检测和纠正严重不足。

优先级判断加两个权重：一是这条控制是否被监管或合同明确要求，二是缺失后能否被现有其他控制部分代偿。两个权重都低的，可以放到下一周期。这张表最大的好处是能把“我觉得该先做日志”变成“检测性控制覆盖率只有 12%，且三条关键检测项均未闭环”，后者在管理层会上更容易过。

4. 中文试译稿的用法：术语对齐、原文回查与版本追踪的三个动作

试译稿的价值是让你快速建立全局认知，但它不是权威文本，稿子开头就写明了“错误或不当之处在所难免，请参照英文原版以准”。这句话不是客套，是使用说明。内部培训、方案草稿、台账提炼都可以基于中文，但凡是要落到合同、审核答复、监管报送的表述，必须回原文核对。

4.1 术语差异：和 GB/T 22081-2016 用词不一致时怎么办

这份 v1.2 的修订说明里提到，部分用词参照 GB/T 22081-2016 做了调整。这意味着中文稿的术语体系是“国际标准语义 + 国标用词习惯”的混合体，和纯直译会有出入。实际会遇到两类冲突：

第一类是同一概念两个译法，比如 supplier 在不同章节出现“供方”和“供应商”，稿子里 5.19–5.22 用的是“供方”，而日常沟通里大家说“供应商”。这类冲突不影响理解，但做制度文件时要统一，建议在术语表里固定一个，全文照用。

第二类是同一译法对应不同原文概念，这类更危险。比如“资产”在 5.9 指 information and other associated assets，在 7.9 指 off-premises assets，范围完全不同。做映射时如果只看中文，容易把两条并成一条。

处理办法是建一张自己的术语对照表，三列：中文词、英文原词、出现章节。遇到拿不准的，回去看第 3 章“术语、定义和缩写词”——这份稿子把术语单独成章，从 3.1 到 3.2 覆盖到第 9 页，是全书最该先读的部分。

4.2 哪些条款必须回查英文原版

不是所有条款都需要回查，全查等于不用中文稿。按我的经验，四类内容必须回原文：

• 带“应/宜/可”情态动词的句子。中文的“应”有时对应 shall，有时对应 should，一字之差在合规判定上是硬伤。
• 涉及数量的表述。比如日志保留周期、审查频次、备份间隔，这类数字错一位就是事故。
• 附录 A 的视图划分和属性标注。表格类内容在翻译中最容易串行。
• 与 27001 附录 A 的对应关系描述。这部分涉及认证依据，必须以原文和正式发布版为准。

反过来，控制指南里的解释性段落、示例、背景说明，读中文完全够用，不必逐句对英文。判断标准很简单：这句话会不会被写进对外文件或被审核员引用？会，就查原文。

4.3 试译稿的版本演进与内部知识库入库

稿子有明确的版本轨迹：v1.1 之后在同年 10 月完成 v1.2 修订，修正了遗漏和不一致。这个细节对内部知识库管理很重要——如果团队里两个人分别存了不同版本，讨论时会出现“我这儿写的是 A，你那儿写的是 B”的经典翻车。

我一般会做三件事：文件命名带版本号和修订日期，比如ISO27002-2022_zh_v1.2_20221027.pdf；在知识库里建一条版本记录，写清每版改了什么、谁引入的、什么时候替换；把引用这份稿子的内部文档全部登记，换版时按登记表逐个更新。

注意：稿子明确允许在保持文件原貌的前提下交流共享。这意味着可以内部传阅、可以引用，但不要拆章改写后当成自己的产出对外发布，也不要去掉版本标识二次分发。

还有一个容易忽略的点：中文稿的章节页码和英文原版对不上。做交叉引用时用章节号，别用页码，否则跨语言对照时全是错位。

5. 避坑：五个真实翻车现场的现象、成因与处置

5.1 把 27002 当认证依据写进 SoA

现象：适用性声明里直接引用 27002 的条款号作为控制目标，审核时被要求整改。

原因：27001 附录 A 才是规范性控制集，27002 是实施指南。两者的编号体系虽然接近，法律地位完全不同。

解决：SoA 的控制目标一律挂 27001 附录 A 条目，27002 只作为“实施参考”列在备注里。台账里的soa_ref字段专门解决这个问题，别混用。

5.2 按编号尾号做新旧版映射

现象：换版时用“旧 A.12.6.1 对应新 8.8”这类规则批量映射，做完发现漏洞管理条款漏了一半内容。

原因：2013 版到 2022 版是重构不是平移，有合并（多个技术漏洞条款收敛为 8.8）、有拆分（事件管理拆成五条）、有新增（5.7 威胁情报、5.23 云服务、5.34 PII 保护、8.11 数据遮盖），编号相近不代表内容对等。

解决：映射表逐条人工对读，每条至少比对控制陈述和指南首段。工作量大但只做一次，做完存成基线，后续版本迭代在这个基线上改。

5.3 自己给控制改属性标签

现象：团队觉得某条控制“明明也是检测性的”，就在台账里加了标签，结果不同人维护的台账口径不一致，按属性筛出来的清单每次都不一样。

原因：2022 版的属性是标准给定的固定标注，不是让你做分类的自定义字段。改属性等于改了统计口径。

解决：属性字段设为只读，从标准抄录，抄完做一次交叉校验（比如抽查十条，回原稿核对）。组织自己的分类需求另开字段，比如internal_tag，和标准属性物理隔离。

5.4 拿试译稿原文写进合同或监管报送

现象：合同附件里的安全控制要求直接引用了中文稿的表述，法务复核时发现与英文原版语义有偏差，返工。

原因：试译稿本身声明以英文原版为准，术语也参照国标做过调整，不具备对外引用效力。

解决：对外文件一律引英文原版条款号加原文摘录，中文只做内部理解。如果确有中文表述需求，走正式翻译流程或引用已发布的国家标准文本。

5.5 只做第 8 章技术控制

现象：落地一年，技术控制覆盖得七七八八，审核时不符合项集中在第 5 章和第 6 章——策略没评审、职责没分离、意识培训记录缺失。

原因：第 8 章 34 条看着最“能干活”，最容易出成果；第 5 章 37 条全是流程和治理，见效慢、责任分散，容易被推后。

解决：用第 3.4 节的属性矩阵做覆盖热力图，按主题列覆盖率。如果某一主题覆盖率明显低于其他，先补这一块，别让技术项把资源吃干净。

6. 进阶验证：用覆盖热力图查出体系里的偏科项

台账建好之后，真正有价值的一步是定期跑覆盖率。做法很简单：以四大主题为行、网络安全概念五功能为列，统计每个格子里的控制条数，再标出其中已实现的条数。一个模拟项目 X 跑出来的样子大致如下（数字是示例，你的填法会不同）：

一眼能看出两个问题：检测和恢复两列的数字整体偏薄，人员控制在检测和恢复上是零。这不是说标准要求人员控制必须覆盖检测，而是说这个组织的落地重心明显压在“保护”上，一旦出事，发现和恢复能力跟不上。验证方法也不复杂：拿这张表去对现有的监控告警清单和应急预案目录，看能不能对上号，对不上的格子就是纸面控制。

另一个进阶技巧是把附录 A 的视图反过来用。附录 A 把 93 条控制按不同视角重新排了一遍，你可以拿它当“第二意见”——自己按主题统计一遍，再按附录视图统计一遍，两次结果如果对同一条控制的归属判断不一致，通常说明这条控制在你的体系里定位模糊，责任人也不清楚。这种模糊项往往就是日后扯皮的地方。

还有一个我踩过的坑值得说：覆盖率别只算“已实现条数 / 总条数”。这个比值会骗人，因为 93 条控制的权重完全不同。更实在的算法是加权——把被监管明确要求、被合同明确约定、以及历史上出过事件的条款权重调高，其余按 1 计。加权之后你会发现，覆盖率虚高的体系会立刻掉下来。

从那以后我每次拿到一份新标准，都强制先跑一遍热力图再动笔写制度，宁可花半天做统计，也不愿三个月后被人问“这条到底谁负责”时答不上来。希望帮到你。

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