简介面向信息安全从业者、合规与体系管理人员以及准备ISO/IEC 27001认证的组织团队ISO/IEC 27002-2022最新中文版提供信息安全控制措施的中文参考。内容围绕信息安全管理体系展开涉及组织控制、控制目标、主题与属性、控制布局、生命周期考虑因素和相关国际标准并保留序、引言、术语定义与缩写词、目录等结构便于按章节查阅和对照英文原版理解新版变化。标准正文按范围、规范性引用文件、术语定义和缩写词、本标准的结构、组织控制等章节组织引言还涵盖背景与语境、信息安全要求、确定控制、制定组织的个性化指南等内容适合体系建设和认证准备时逐项对照。资源包共1个PDF文件大小约44.41MB适合在电脑端检索阅读。已有351人学习可作为数据安全治理、网络安全控制落地和体系文件编制的案头资料帮助读者快速定位控制条目、梳理实施思路并查漏补缺。1. 93 个控制不是一张清单而是一套可推导的索引把 ISO/IEC 27002 当成一张勾选清单是信息安全管理体系落地时代价最大的误会。2022 版把控制数量从 114 压到 93同时给每条控制挂上五类属性标签还砍掉了「控制目标」这一整层——它真正想让你做的是以风险为输入、从 93 条里推导出属于自己组织的那一份而不是照着目录逐条打勾。这套推导规则值得认真理解审核现场看的从来不是你勾了多少条而是你能不能讲清某一条为什么被选中、另一条为什么被裁掉。这份中文试译稿的价值恰在此处它把结构层面的改动完整搬了过来包括此前只在英文原版里才看得清的主题划分、属性标注和控制布局。2. 从 114 到 93控制合并的判据与新增的空白新版目录本身就给出了一个可验证的数字第 5 章组织控制 37 条、第 6 章人员控制 8 条、第 7 章物理控制 14 条、第 8 章技术控制 34 条合计 93 条。数量变化是最表面的现象真正值得关注的是这次合并的处理依据。2.1 归并的依据控制陈述能不能一句话说完2013 版处理日志用了三条独立控制事件日志、日志信息的保护、管理员和操作员日志。2022 版把它们压成 8.15 一条控制陈述变成连着四个动词的句子——产生、存储、保护、分析。这四个动词恰好覆盖同一份日志产物的四个处理阶段。合并的依据就此显现当多条控制的实施对象是同一个产物、彼此只差阶段时就可以收成一条带多动词的陈述把细节交给指南按阶段展开。2013 版控制簇2022 版控制合并依据事件日志 / 日志保护 / 管理员操作员日志8.15 日志同一产物的产生、保护、特权操作记录三个阶段加密控制策略 / 密钥管理8.24 密码学的使用策略与密钥生命周期无法分开评估访问控制的业务要求 / 网络服务访问5.15 访问控制业务决策与网络侧执行是同一链条的两端事件管理七条5.24–5.28按时间线准备、评估决策、应对、复盘、取证重排供方关系三条5.19–5.22反向操作按实施主体拆开最后两行是关键的反例。事件管理和供方关系没有被合并反而被拆得更细。这说明处理依据是「这条控制能不能被独立评估」条目数量多还是少并不是判断标准。供方关系里签协议、管供应链、监视服务表现、处理变更实施主体和执行时点完全不同强行合并会让审计抽样失去抓手而事件管理按时间线重排后每条都能对应到一个明确的组织角色拆比合更利于追责。合并的副作用是追溯链条断裂。旧版编号在组织内部文档里用了很多年风险登记表、内审检查表、供应商问卷全都挂着旧编号。合并之后一份 2019 年写的风险处置计划里的「A.12.4.1」在新版里找不到对应字面。常见的做法是维护一张双向映射表并固化进配置管理库表里至少要有旧编号、新编号、映射类型等价 / 部分覆盖 / 拆分 / 新增、覆盖度说明。哀痛经验是这张表一旦靠人脑记两轮内审之后必然出现两份互相矛盾的版本。2.2 新增控制补的是生命周期的两端新增的十一条控制集中在几个明显的位置。识别端有 5.7 威胁情报、8.9 配置管理、5.30 ICT 为业务连续性做好准备数据端有 5.34 PII 隐私和保护、8.10 信息删除、8.11 数据遮盖、8.12 防止数据泄漏观测端有 8.16 活动监视、8.23 Web 过滤、7.4 物理安全监视开发端有 8.25 安全开发生命周期、8.28 安全编码、8.31 开发、测试和生产环境的分离。把这些点连起来看规律很清楚新版把控制的作用域从「系统运行期」往两头拉长最左拉到威胁情报最右拉到数据销毁。这正是引言 0.6 节「生命周期考虑因素」在控制集合上的落地。2013 版对新威胁形态的覆盖是间接的——威胁情报要靠风险评估自己补云服务的控制点散在供方关系里数据删除几乎没有独立控制。2022 版把这些空白直接补成条目。这里有一组必须成对理解的机制。8.10 信息删除和 8.13 信息备份是互逆操作备份策略决定了删除的难度删除要求反过来约束备份的保留期设计。只做备份不做删除结果是数据在备份介质里永久留存删除请求根本无法真正兑现只做删除不做备份可用性直接失守。同样8.11 数据遮盖和 8.12 防止数据泄漏也是成对的——前者缩小静态暴露面展示层脱敏、测试数据脱敏后者管动态外发通道两条都做才构成完整的暴露面收敛。提示把 8.10 和 8.13 放在同一份方案里评审否则备份保留期会成为删除合规的最大障碍。3. 五类属性把 93 条控制变成可查询的多维索引如果只有主题分组2022 版不过是把 2013 版的目录换了个排法。真正改变使用方式的是属性attribute机制——每条控制额外挂五类标签于是同一批控制可以按五种不同维度重新排列。3.1 属性字段的取值域与多值特性属性取值域解决的问题控制类型预防性、检测性、纠正性判断控制落在事件前、中、后哪一段信息安全属性机密性、完整性、可用性与经典 CIA 三元组对齐网络安全概念识别、保护、检测、响应、恢复与主流网络防御生命周期五阶段对齐运行能力治理、资产管理、身份与访问管理、威胁与漏洞管理、事件管理、连续性等映射到组织内的职能团队安全域治理与生态、保护、防御、韧性用于向管理层做分层汇报多数控制是多值标签。以 8.15 日志为例它同时具备检测性和纠正性同时覆盖机密性、完整性、可用性——日志本身是敏感数据要保护它的机密性日志是篡改检测的依据服务于完整性日志写满会拖垮系统所以也有可用性考量。这种多值设计不是含糊而是刻意保留因为它让「一条控制对应多个风险点」这件事在数据结构上成立。标准附录 A 把这些属性做成了若干张视图表等于官方预先建立好的索引。但视图是单一维度的纵切实际选型几乎总是组合查询所以真正要靠的还是自己建一份可查询的表。3.2 用属性做筛选从「翻目录」到「跑查询」假设一个具体场景内容管理系统上线后业务方担心页面内容被越权改写。用属性来描述这个风险就是「完整性受损且需要能检测出来」。下面这段把索引跑一遍。# 演示用的小样本真实落地时从附录 A 的视图表批量导入 93 条 CONTROLS { 8.15: {name: 日志, type: {检测性, 纠正性}, cia: {机密性, 完整性, 可用性}, csf: {检测}, cap: {事件管理}}, 8.16: {name: 活动监视, type: {检测性}, cia: {完整性}, csf: {检测}, cap: {事件管理}}, 8.9: {name: 配置管理, type: {预防性}, cia: {完整性}, csf: {保护}, cap: {安全配置}}, 8.8: {name: 技术漏洞的管理, type: {预防性}, cia: {完整性, 可用性}, csf: {识别}, cap: {威胁与漏洞管理}}, } def candidates(need_cia, need_csf, need_typeNone): 按属性筛控制CIA 与生命周期阶段同时命中才入选类型用于二次收窄 hit [] for cid, meta in CONTROLS.items(): if need_cia meta[cia] and need_csf meta[csf]: if need_type is None or need_type meta[type]: hit.append((cid, meta[name])) return hit # 场景内容被越权改写先找“能发现”的控制排除纯预防性 print(candidates({完整性}, {检测}, {检测性})) # 输出: [(8.15, 日志), (8.16, 活动监视)]参数都用集合而不是字符串因为属性本身是多值的用集合的交集运算做匹配最直接。函数做了两级筛选先用 CIA 和生命周期阶段确定方向再用控制类型排除纯预防性控制——排掉之后剩下的就是「出事之后能给出证据」的那一类。全量导入 93 条之后这个函数通常会稳定返回 3 到 8 条候选数量刚好够开一次风险处置讨论不至于让人无从下手。这一步的意义在于词表统一。风险描述里天然会出现「完整性」「检测」这类词控制条目上挂着同一套词匹配就退化成机械动作。2013 版没有这层映射只能拿控制目标的标题做模糊匹配匹配质量完全取决于命名习惯难以稳定复现。4. 控制条目的固定布局目的、陈述、指南三层为什么不能混4.1 三层文本的职责边界标准第 4.3 节专门讲「控制的布局」它规定每条控制都由固定的几段组成顺序也固定。层语气可裁剪性在审核中的角色控制陈述规范性「应」不可裁剪只有适用 / 不适用判定项控制目的解释性说明这条控制消解什么风险随控制绑定论证适用性理由指南建议性「考虑」「宜」可裁剪实施参考不作判定依据其他信息引用性—交叉索引把 why 和 how 从 shall 里剥出来是这一版最实用的一处结构改动。2013 版的控制目标只到「组」这一级落到单条控制时只能从标题猜意图现在每条控制自带一段目的描述这段文字经过改写就能进适用性声明的「适用理由」栏。三层分得这么清是为了让「要求」和「建议」在文本层面就隔开避免把指南里的某个具体做法当成强制项。注意审核现场最常见的争议是把指南里的某个示例当成必须实现的产品或流程。判断依据看语气词不看内容像不像。4.2 从一句 shall 拆到证据以 8.15 日志为例控制陈述是一句规范性语句它描述的是要达成的状态不是要执行的动作。所以落地时第一件事是拆动词。control: 8.15 日志 statement: 应产生、存储、保护和分析记录活动、异常和事件的日志 # 四个动词 四组可验证证据缺任意一组这条控制就是部分失效 evidence: - 产生: 日志源清单 各源字段定义主体、时间、操作、对象、结果 - 存储: 保留期配置含法务与合同要求 容量与滚动策略 - 保护: 写权限收敛记录 完整性校验机制哈希链或只写存储 - 分析: 关联规则或告警阈值定义 告警处置工单抽样 selfcheck: 有日志无分析是这条控制最典型的部分失效形态statement 直接引用控制陈述原文保证与标准对齐evidence 每一条必须能指向一个具体文件、系统截图或工单编号指不到就是没做selfcheck 是自查项用来在做内审前先暴露问题。拆动词的逻辑在于审计是抽样抽样单位是动词而不是整条控制。审核员问「你有日志吗」和问「你怎么用日志」是两次独立的取证前者对应产生和存储后者对应分析。这条链路是三段式的27001 附录 A 只给出第一段的 shall27002 补上 why 和 how适用性声明补上「这是不是我的问题」证据补上「我做了没有」。任何一段缺失都会在审核现场以「无法提供客观证据」的形式暴露出来。5. 中文版本实施时的常见误读5.1 把「指南」读成「要求」文本层的两个坑现象某团队把 8.15 的指南里提到的日志集中采集、独立存储介质、定期评审规则全部列为硬性交付物结果在一个只有三台服务器的边缘业务上也要建一套独立日志平台成本直接压过业务收益。原因指南部分用的语气是「考虑」「宜」它描述的是可选的实现路径族不是唯一的合规形态同时试译稿在部分段落沿用旧版国标译法语气强度在中文里不如英文原版明显。解决拿到任何一条控制先按三层结构切分只把控制陈述列为判定项指南里的做法一律标注为「可选实现」并写清楚在本组织语境下选了哪一条、为什么。现象内部培训时把事件event和事态incident当同义词混用导致事件分级标准写成了「所有安全事件都要上报」。原因5.25 事态的评估和决策这一条的前提恰恰是事态与事件在语义上被刻意区分——事件是发生的现象事态是经评估后被认定为需要处置的那一类。译文对这两个词的区分在部分章节保持得不够一致直接照抄会丢失这层语义。解决建一份中英对照术语表凡是涉及分级、上报、时限的条款一律回查英文原版术语表本身纳入配置管理。5.2 主题归属与新旧映射实施层的三个坑现象做覆盖度盘点时算出组织已覆盖 80%内审时被判定实际覆盖不足。原因用新版编号去对旧版检查表把合并控制当成等价替换。8.15 日志接收了三条旧控制旧检查表里只做过其中一条却被记成整条已覆盖。解决映射表必须标注映射类型部分覆盖的条目要做缺口分析等价替换才允许直接勾选。现象把 6.8 报告信息安全事态归到事件管理流程里去审结果发现流程文档对不上。原因6.8 位于人员控制章它约束的是「人发现异常后怎么报」属于意识与行为层面5.24 到 5.26 才约束组织的流程与响应能力。两者对象不同审计证据也不同一个是培训记录与上报渠道可用性一个是响应预案与处置记录。解决主题归属以章的划分优先属性只用于二次筛选不要用属性覆盖主题。现象内部制度文件引用这份试译稿时没标版本两份文件对同一条控制的表述不一致评审会上各执一词。原因试译稿经过修订部分用词向后调整过不同时间下载的副本内容并不相同。解决所有引用标注「试译稿版本号 对照英文原版为准」并明确冲突时以英文原版为准同时把译文文件纳入文档版本控制和制度文件同批发布。6. 取舍控制目标下沉是这一版最值钱也最危险的设计取消「控制目标」这一中间层把目的下沉成每条控制自带的一个字段收益是显而易见的控制与风险点变成一对一的可论证关系适用性声明可以逐条写理由而不必先归类再解释。代价同样明显——原来一组成员共同服务一个目标的整体视角消失了。五条控制原本属于同一个控制目标现在散在四个不同位置各自成立、各自合规但合起来未必构成一个完整的防护面。验证这件事最好的办法是走一遍闭环挑一个具体风险比如「审计日志被篡改导致事后无法追责」用属性筛出候选控制8.15、8.16、8.9 大概率会同时出现逐条落到控制陈述再把陈述拆成证据。如果拆完发现证据只覆盖了产生和存储、没人负责分析告警那说明组织实现的是单条控制的合规而不是一个控制族的闭环。这个检查我通常放在风险评估收尾阶段做成本很低但能捞出大部分「条目全绿、防护有洞」的情况。进阶一点的做法是自建一张属性索引表把 93 条控制的五类属性全部结构化再额外加两列本组织的责任团队、上次取证时间。有了这两列选型就从「查标准」变成「查自己的库」团队交接时也不至于全凭记忆。从那以后我每次做控制适用性评审都强制走一遍「属性筛选 → 控制陈述 → 证据拆分 → 责任团队确认」这四步少一步就会在后面某个环节补回来。这份试译稿正好能当这条链路的起点拿它把 93 条控制过一遍比读十篇解读都实在。希望帮到你。本文还有配套的精品资源点击获取