企业官网建设流程全解析

简介：面向信息安全从业者、合规与体系管理人员，以及准备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 一条，控制陈述变成连着四个动词的句子——产生、存储、保护、分析。这四个动词恰好覆盖同一份日志产物的四个处理阶段。合并的依据就此显现：当多条控制的实施对象是同一个产物、彼此只差阶段时，就可以收成一条带多动词的陈述，把细节交给指南按阶段展开。

最后两行是关键的反例。事件管理和供方关系没有被合并，反而被拆得更细。这说明处理依据是「这条控制能不能被独立评估」；条目数量多还是少，并不是判断标准。供方关系里，签协议、管供应链、监视服务表现、处理变更，实施主体和执行时点完全不同，强行合并会让审计抽样失去抓手；而事件管理按时间线重排后，每条都能对应到一个明确的组织角色，拆比合更利于追责。

合并的副作用是追溯链条断裂。旧版编号在组织内部文档里用了很多年，风险登记表、内审检查表、供应商问卷全都挂着旧编号。合并之后，一份 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 属性字段的取值域与多值特性

多数控制是多值标签。以 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_type=None): """按属性筛控制：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 只给出第一段的 shall，27002 补上 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 条控制过一遍，比读十篇解读都实在。希望帮到你。

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