企业官网建设流程全解析

简介：《ISO/IEC 27002-2022最新中文版》面向信息安全管理体系（ISMS）建设者、安全咨询顾问、合规审计人员及认证备考者，提供新版信息安全控制指南的中文参考，帮助读者理解组织如何依据该标准定制并实施控制措施，适合安全治理、风险管理与第三方合规检查场景查阅。压缩包内共1个PDF文件，约44.41MB，主体为中文试译稿v1.2，含序、引言、术语与定义、标准结构、组织控制等章节，覆盖信息安全控制、网络安全、数据安全治理、控制目标、生命周期考虑因素和相关国际标准等主题。已有351人学习。读者可借助目录和章节布局梳理新版控制在背景语境、控制属性及组织个性化指南方面的变化，也可将其用于咨询交付、体系文件修订和内部培训时的条款对照，快速定位控制目标并理解控制意图，进而对控制措施之间的关联形成整体认识；试译稿使用时仍宜参照英文原版核校。

1. 从 114 条压到 93 条：这份 2022 版中文试译稿能解决什么

某团队做年度内审，翻出 2013 版的 14 个域 114 项控制清单逐条对现场，对到供应商那一栏卡住了：新业务大半跑在云上，旧清单里找不到一条能落在「云服务」上的位置。这不是执行不到位，是底稿过期。2022 年 2 月 ISO/IEC 27002:2022 发布，控制项从 114 条压到 93 条，按组织、人员、物理、技术 4 个主题重排，还挂了一套属性标签。手上这份中文试译稿 v1.2 在 2022 年 10 月完成修订，术语向对应国标版本做过对齐，正文覆盖术语与定义、标准结构说明、93 项控制全文，以及属性汇总附录。它解决的是「手里有 27002 信息安全管理体系的旧底稿、要按新结构重做控制裁剪和差距分析」这件事，适合正在维护体系文件、准备内审或换版的人。

2. 拆开目录读结构：4 个主题、93 项控制与六段式控制布局

拿到一份标准文本，直接从第 5 章第一页开始逐条抄，是效率最低的读法。2022 版最大的改动不在某一条控制的具体措辞，而在组织方式——旧版按「职能条线」切，新版按「控制作用的对象」切，切法一变，控制编号、属性、与认证标准的对应关系全都跟着变。先把结构吃透，后面每一条控制才知道自己该放在体系的哪个格子里。

2.1 14 个域为什么被压成 4 个主题

2013 版的分类逻辑是按部门职能走：访问控制一个域、通信安全一个域、运行安全一个域、系统获取开发与维护一个域。这种切法在纸面上整齐，落到现场经常撞车——同一条「限制对信息的访问」，访问控制域里有，运行安全域里也有，资产管理域里还沾一点，执行的人分不清该看哪一条。2022 版换成按作用对象切：组织层面的控制归到第 5 章，跟人相关的归第 6 章，物理环境归第 7 章，技术手段归第 8 章。同一条控制的重复表述被合并，跨域的重叠被拆到不同层面去讲。

用一条线看更清楚。旧版 A.9 访问控制下的多条控制，在新版被拆成 5.15 访问控制（策略层）、5.18 访问权限（授权流程层）、8.2 特殊访问权（特权账号层）、8.3 信息访问约束（数据与功能层）、8.5 安全身份认证（认证机制层）。同一件事被分散到组织和技术两个主题，是因为「谁批权限」属于治理动作，「用什么认证」属于技术实现，两者责任人和证据形态完全不同。旧的分类把它们压在一起，审计时要一份文件同时证明流程和技术，很难取证。

主题之间的数量分布也值得记一下：组织 37 项（5.1 到 5.37）、人员 8 项（6.1 到 6.8）、物理 14 项（7.1 到 7.14）、技术 34 项（8.1 到 8.34）。组织类占了四成，这个比例本身就是个信号——新版把治理、供应链、事件管理、合规这些「管事」的内容大幅前置，技术控制反倒不是数量最多的一块。很多团队换版时把精力全砸在第 8 章，做完发现 SoA 里最空的是第 5 章。

新增的 11 项控制全部能在这份译稿的目录里查到，建议单独拉一张表盯住，因为它们大概率是现有体系的空白：

这 11 项的共同点很明确：云、数据、检测、开发安全。旧版体系里「防」的比重极高，「发现」和「数据生命周期末端」几乎空白，新增项基本是照着这几块补的。做差距分析时优先过一遍这张表，比逐条比对 93 项快得多。

2.2 一项控制的六段式布局：从控制陈述到补充信息

第 4 章 4.3 节专门讲控制的布局，这是读正文的钥匙。每一项控制都由固定的六段构成，顺序不变，含义也不变：

关键在于「控制」和「控制描述」是两回事。前者是要求，后者是做法。以 8.8 技术漏洞的管理为例，控制陈述讲的是「应及时获取技术脆弱性信息、评估暴露程度并采取适当措施」，而描述部分会展开成资产台账、漏洞扫描频率、风险评级口径、修补时限、例外处理几个动作。做体系文件时，陈述进方针，描述进程序文件和作业指导书，两者混在一份文件里，内审时会被追问「你这条到底是要求还是操作步骤」。

「目的」这一段最容易被跳过，实际它是最好用的。写风险处置计划时经常卡在「为什么选这条控制」，目的段落已经把答案写好了，稍作改写就能填进 SoA 的理由栏。至于「补充信息」，它指的是相关控制的交叉引用，用它可以快速找到一条控制的上下游——比如做漏洞管理时会牵出 8.32 变更管理、5.7 威胁情报、8.19 在操作系统上安装软件，这三条不一起做，漏洞管理的闭环就是断的。

2.3 从目录反查控制：用编号定位条款的实践路径

编号规则很简单：主题号加点序号，5.x 是组织、6.x 是人员、7.x 是物理、8.x 是技术。旧编号 A.x.y.z 那套四段式已经废弃，但存量文件里到处都是旧编号，换版时最费时间的活就是做映射。常见做法是先建一张新旧对照表，把旧编号、旧名称、新编号、新名称、变更类型（合并/拆分/新增/删除）五列拉齐，之后所有整改任务、内审检查表、制度修订记录都挂这张表走。

如果手上只有一份纯文本或可复制的中文译稿，用两条命令就能把控制标题抽成扁平索引，比手工翻目录快：

# 抽出第 5～8 章的控制标题行，带行号方便回查原文 grep -nE '^[5-8]\.[0-9]+[[:space:]]+[^[:space:]]' 27002.txt > control_index.txt # 按主题号统计条数，核对是否为 37/8/14/34 sed -E 's/^[0-9]+:([5-8])\..*/\1/' control_index.txt | sort | uniq -c

第一条命令的-n保留行号，-E启用扩展正则，^[5-8]\.[0-9]+匹配「主题号.序号」开头，后面跟空白再接非空白字符，这样能过滤掉正文里以数字开头的普通句子。第二条用sed把行号和序号都剥掉，只留主题号一位数字，再交给sort | uniq -c统计。跑完如果第 5 章不是 37 条、第 8 章不是 34 条，说明抓取规则漏了标题换行的情况，需要回原文看是不是标题被折行了。这一步看着琐碎，但索引建好之后，写检查表、做属性录入都靠它当底表，省下来的是后面几个小时的手工核对。

3. 五类属性怎么用：把 93 项控制拆成可筛选的矩阵

属性是 2022 版最不显眼、也最容易被浪费的改动。多数人翻到属性表扫一眼就过去了，觉得就是几个勾选框。实际这五类属性是五套互相独立的切分视角，同一项控制在不同视角下位置不同，合起来能回答「我的控制组合偏不偏」「哪类风险没人接」这种靠逐条读文本答不上来的问题。

3.1 属性不是标签，是五套不同的切分视角

控制类型分预防性、检测性、纠正性三类，回答的是「这条控制在哪一环起作用」。这是最实用的一类属性——一个体系如果九成控制都是预防性，说明它只会堆防线，出事之后既发现不了也收不了场。检测性和纠正性控制的数量，往往比总数更能反映成熟度。

信息安全属性对应保密性、完整性、可用性，一条控制可以同时命中多个。这一类用来跟风险评估的损失维度对齐：风险清单里按 C/I/A 归类之后，直接筛属性就能看出哪个维度缺控制。比如「数据被篡改」类风险落在完整性上，如果完整性属性的控制只有备份和校验两条，缺口就很明显。

网络安全概念分识别、保护、检测、响应、恢复五段，跟运营流程的阶段划分一致。这一类适合跟安全运营团队对齐口径，把控制项映射到日常值班、告警、处置、复盘这几个环节上，能直观看到响应和恢复两段是不是空的。

运行能力维度按治理、资产管理、信息保护、人力资源安全、物理安全、系统和网络安全、应用安全、安全配置、身份与访问管理、威胁和漏洞管理、事件管理、业务连续性、法律和合规等能力分组，这一类跟部门职责对齐最顺。拿它做分工表，一项控制归哪个组维护，基本不用再吵。

安全域分治理与生态系统、保护、防御、韧性四类，颗粒度最粗，适合向管理层汇报。四类的分布能一句话讲清体系重心：治理与生态系统类多，说明偏重制度和供应链；防御类多，说明偏重技术对抗；韧性类少，说明业务连续性和恢复能力是短板。

最后一行值得多说一句。安全域是描述性标签，不是适用性判据，不能因为某项控制落在「治理与生态系统」就觉得它跟自己无关。适用不适用，取决于业务边界和风险评估结果，属性只告诉你这条控制长什么样，不告诉你该不该要。

3.2 把属性表录成结构化清单：字段设计与录入口径

附录里的属性汇总表适合人看，不适合筛选。要做分析，得先把 93 条控制的属性和本组织的适用状态录成一张结构化表。字段设计上，控制本身的客观属性和本组织的主观状态要分开，前者来自标准，后者来自体系运行，混在一张表里改起来会互相污染。

多值字段用竖线分隔而不是逗号，是因为 CSV 本身用逗号分列，多值再塞逗号就得加引号转义，Excel 来回另存几次必然出错。in_scope用三档而不是布尔值，是因为现实中大量控制处于「部分适用」状态，只有是/否两档会逼着人做违心判断，最后整张表失去可信度。责任方写岗位不写人名，人员一变动整张表就得重录，血的教训。

录完之后大概长这样：

control_id,control_name,theme,control_type,cia,cyber_concept,capability,domain,in_scope,evidence_owner,evidence_ref 5.7,威胁情报,组织,预防性,保密性|完整性|可用性,识别,威胁和漏洞管理,治理与生态系统,yes,安全运营岗,TI-FW-01 8.16,活动监视,技术,检测性,保密性|完整性|可用性,检测,事件管理,防御,partial,安全运营岗,MON-CFG-03 8.10,信息删除,技术,预防性,保密性,保护,信息保护,保护,no,系统运维岗,

第三行in_scope是 no 且evidence_ref为空，这正是差距分析的输入——不适用的控制必须有理由，理由单独放一列或者写在 SoA 里，不能就这么空着，否则内审一问就穿帮。

3.3 一次差距分析的筛选脚本与结果解读

底表录完，用一段脚本把三个最常问的问题一次跑出来：控制类型分布、检测性控制的缺口、各主题的纳入率。

import csv from collections import Counter # utf-8-sig 是为了兼容 Excel 另存出来的 BOM，否则第一列字段名会带不可见字符 with open("control_matrix.csv", encoding="utf-8-sig") as f: rows = list(csv.DictReader(f)) # 口径一：控制类型分布，多值字段先拆开再统计 type_counter = Counter() for r in rows: for t in r["control_type"].split("|"): if t: type_counter[t.strip()] += 1 total = sum(type_counter.values()) for t, c in type_counter.most_common(): print(f"{t}: {c} ({c / total:.0%})") # 口径二：检测性但未纳入或部分纳入的控制，通常就是监控盲区 gaps = [r for r in rows if "检测性" in r["control_type"] and r["in_scope"] != "yes"] for r in gaps: print(f'缺口 {r["control_id"]} {r["control_name"]} 责任方={r["evidence_owner"]}') # 口径三：按主题统计纳入率，定位拖后腿的那一块 for theme in ("组织", "人员", "物理", "技术"): sub = [r for r in rows if r["theme"] == theme] if not sub: continue ok = sum(1 for r in sub if r["in_scope"] == "yes") print(f"{theme}: {ok}/{len(sub)} = {ok / len(sub):.0%}")

第一段用DictReader按表头取字段，避免列顺序变化导致错位；多值字段按竖线拆开再计数，否则「预防性|检测性」会被当成一个新类别，统计结果直接失真。第二段是核心筛选，条件是「控制类型含检测性」且「纳入状态不是 yes」，这类控制要么没做、要么做了一半，是最该排期的部分。第三段按主题算纳入率，用来判断缺口是全局性的还是局部的。

结果怎么读，有几个经验阈值。检测性控制在全部控制类型里的占比低于两成，基本可以判定这个体系缺发现能力，日志、监视、漏洞扫描这几块要重点看。某个主题的纳入率明显低于其他主题，先分清是真不适用还是没识别：物理主题纳入率低，如果业务全在托管机房，可能是合理的；技术主题纳入率低，几乎不可能是合理的，多半是没做。还有一类情况要注意，in_scope全是 yes、evidence_ref大面积为空，这不是覆盖率高，是纸面体系，脚本跑出来的数字好看，一取证就崩。

4. 落到认证标准的 SoA：控制选择、风险处置与证据链

标准文本读得再熟，最终要交出去的是一份能过内审、能支撑认证的适用性声明。SoA 不是把 93 条控制抄一遍打勾，它是风险处置结果和控制选择理由的汇总，写不好就是一张没有信息量的清单。

4.1 0.4 与 0.5 两节的价值：确定控制不是照抄 93 条

引言里的 0.4「确定控制」和 0.5「制定组织的个性化指南」这两节，篇幅不长，但决定了整份标准的用法。0.4 讲的是控制从哪里来：从风险评估和信息安全要求出发，27002 里的 93 项控制是参考控制集，不是必须全上的清单。0.5 讲的是怎么落地：标准语言是通用表述，组织要把它翻译成自己的方针、程序、作业指导书三层文件。

这两节合起来给出的路径是：风险场景 → 控制候选 → 适用性判定 → 实施优先级。跳过第一步直接对着 93 条打勾，做出来的 SoA 会有一个典型特征——所有控制的适用理由都是「行业惯例」或「合规要求」，没有一个能追溯到具体风险。这种 SoA 在认证审核时最容易被追问，因为审核员顺着理由往回找，找不到对应的风险条目。

常见做法是先建风险清单，每条风险至少标注受影响的 C/I/A 维度和业务场景，然后拿属性表做匹配：风险落在完整性上，就筛 cia 字段含完整性的控制；风险场景是外部攻击，就叠加 cyber_concept 里的检测和响应。匹配出来的候选集通常比 93 条小很多，再逐条做适用性判定，工作量能降一个量级，理由也天然站得住。

判定适用性的时候有个容易走偏的地方：把「暂时没做」当成「不适用」。两者在 SoA 里的含义完全不同，前者是实施状态为未完成，后者是这项控制跟本组织业务无关。混在一起的后果是差距被掩盖，明年再看还是同一批控制没做。

4.2 SoA 的适用范围声明怎么写才不空

一份能用的 SoA 至少要有这几列，缺一列都会在审核时被追着问：

「不适用理由」这一列是重灾区。写「不涉及」等于没写，审核员会直接问「凭什么不涉及」。合格的写法要落到业务边界和替代安排上，比如某项物理控制不适用，理由应该说明场所是托管机房、该控制由托管方按合同承接、取证方式是年度供应商评审报告，而不是一句「无自建机房」。理由写到这个程度，既解释了为什么不做，也交代了风险怎么被接住，逻辑才闭合。

实施状态这一列同样要克制。全部标「已实施」的 SoA 看起来漂亮，实际是把风险后移——一旦抽查到某项控制拿不出证据，问题就从「进度滞后」升级成「记录不实」。三档状态配合证据引用，反而是最稳的写法。

4.3 证据链：从控制描述落到可审计的记录

控制描述里的动词，基本决定了证据的形态。这一步做扎实，内审前不用突击补材料。

以 8.15 日志为例，控制描述会涉及事件日志的记录、存储、保护和分析几个动作。对应到证据，就不是一份《日志管理规定》能交差的：记录对应日志源清单和采集配置，存储对应留存周期设置，保护对应访问权限和完整性校验，分析对应告警规则和处置工单。四个动作四类证据，缺哪个环节，控制就是断的。

同一个思路可以反过来用：先看证据齐不齐，再判断控制实施到什么程度。收集证据时按「文件—记录—系统」三层走，文件证明有制度，记录证明执行过，系统证明还在跑。只有文件没有记录，是纸面制度；只有记录没有文件，是野路子操作；三层都有且能互相对上，才算闭环。这套判断标准比任何自评表都实在。

5. 避坑与排查：中文试译稿用起来最容易翻车的四个地方

试译稿是交流版本，译者在说明里写得很清楚——以英文原版为准。这句不是客套，是使用前提。下面四条都是实际用下来反复出现的问题，按「现象 → 原因 → 解决」拆开写。

5.1 把指南当认证依据：审核员问「不符合哪一条」时答不上来

现象：内审时拿 27002 的控制条目当检查项，逐条判符合或不符合，开出的不符合项报告上写着「不符合 27002 第 8.9 条」，被审核方反问依据是什么。

原因：27002 是实施指南，不是认证要求。认证依据的是管理体系标准的要求条款加其附录 A 的控制集，27002 提供的是这些控制怎么实施的说明。拿指南条款开不符合项，逻辑上不成立，因为指南用的是「宜」而非「应」的表述强度。

解决：检查表分两层，第一层对着认证标准的要求条款和附录 A 控制编号判符合性，第二层用 27002 的描述作为「实施是否充分」的参考。不符合项只挂第一层的条款号，27002 的条款号写在观察项或改进建议里。这个区分在换版初期尤其重要，很多团队两套编号混着用，报告写出来自己都理不清。

5.2 拿属性表当裁剪依据：筛完发现控制组合还是偏

现象：按属性筛出所有检测性控制，做了一批监视和日志的投入，年底复盘发现事件平均发现时间没降多少。

原因：属性描述的是控制的特征，不是控制的效果。某项控制被标为检测性，只说明它在「发现」这一环起作用，不代表它对本组织的关键风险有效。更常见的问题是只看单条属性，没看组合——检测性控制再多，如果没有配套的响应流程和分级口径，告警只会变成噪音。

解决：属性用来找缺口，不用来做决策。筛出候选集之后，必须回到风险清单验证：这条控制对应的风险场景在本组织是否存在，现有的告警规则能不能覆盖。另一个实用做法是做属性交叉表，比如「检测性 × 事件管理能力」这个格子里的控制数量，比单看检测性总数更能说明响应能力。交叉表为空或者只有一两条，基本可以确定这块是空的。

5.3 新旧编号混用：整改任务派下去对不上号

现象：制度修订任务里写着「按 A.12.6.1 完善漏洞管理」，执行的人翻遍新版找不到这个编号，改完的文件又用了新编号 8.8，两版文件同时在用。

原因：换版时只更新了部分文件，映射表没建或者建了没维护。旧编号 A.x.y.z 和新编号不是简单的一对一，合并、拆分、新增、删除四种情况都有，凭记忆转换必然出错。

解决：先建一张五列映射表（旧编号、旧名称、新编号、新名称、变更类型），所有制度、检查表、整改任务、培训材料统一挂这张表走。变更类型这一列别省，标「拆分」的条目要列出拆到了哪几条新控制，标「合并」的要注明来源有哪几条，否则追溯的时候还是断的。这张表建一次能用好几年，后面每次内审、每次文件修订都要回查。

5.4 术语口径不统一：同一份文件里两种说法打架

现象：体系文件里一会写「控制目标」，一会写「控制」，一会写「控制措施」，内审时被问「这三个是不是一回事」。

原因：2013 版是「控制目标 + 控制措施」的两层结构，2022 版取消了这个分层，统一叫「控制」，下面再分目的和描述。试译稿在翻译时对部分用词做了调整，向对应国标版本靠拢，但组织自己的存量文件没跟着改，新写的文件又混用了旧习惯，两套口径就并存了。

解决：换版时同步做一次术语对照表，把旧术语、新术语、使用场景三列列清楚，附在体系文件编制规范后面。写文件前先查表，别凭手感。遇到译稿里表述拿不准的条款，回英文原版对照，这是译者在说明里就交代过的原则——试译稿的价值在于降低阅读门槛，不在于替代原文。争议条款、合同引用、对外声明这几类场景，一律以英文原版为准，别图省事。

6. 进阶：用属性汇总附录做一次三向交叉验证

体系文件做完，最怕的是「看起来都对，一查就断」。介绍一个我常用的自检方法，材料就是属性汇总附录加上前面那张控制矩阵，不用额外工具，半天能跑完一轮。

三向交叉验证的意思是：风险、控制、证据三个方向两两对齐，任何一向对不上就是断点。

第一向最容易发现「虚风险」。风险清单里挂着一条「核心数据泄露风险」，往下找控制，SoA 里只勾了访问控制和加密，没有数据泄漏防护、没有活动监视、没有事件响应。这不是控制选少了，是风险分析没做透——泄露的路径、时点、发现手段一个都没拆。遇到这种情况，回 5.7 威胁情报和 8.12 防止数据泄漏这两条控制的描述段落，按里面的实施要点把风险场景补全，再重新匹配。

第二向是查纸面体系。做法很机械：把矩阵里in_scope为 yes 的行筛出来，逐行看evidence_ref是否为空。空的比例超过两成，说明体系文件跑在了执行前面，这时候补文件没用，得先去补执行记录。有一类特殊情况要注意，控制确实做了但没有留痕，比如权限审批走了口头，这种要补的不是证据而是流程，把审批动作挪到系统里，记录自然就有了。

第三向看分布。把控制类型和安全域做成交叉表，四个安全域乘以三种类型，十二个格子里看哪个是零。治理与生态系统加上预防性通常很密，防御加检测性也还行，韧性加上纠正性这一格经常是空的——业务连续性和恢复相关的控制本来就少（5.29、5.30、8.13、8.14 这几条），再一分摊，纠正性控制就所剩无几。这一格空了不是补文件能解决的，得靠恢复演练和备份验证撑起来，属于要排期的硬投入。

跑完一轮，输出三张清单：风险无控制承接的、控制无证据支撑的、属性分布异常的。三张清单的优先级不一样，第一张最急，因为它意味着风险敞口没人管；第二张次之，属于记录债；第三张是长期改进项，按季度推。

有个习惯我保持了几年：每次换版或者体系大修之后，不管自评表填得多漂亮，都强制把这三向跑一遍，尤其是第二向那个「筛出 in_scope=yes 再看 evidence_ref 是否为空」的动作，机械、枯燥，但每次都能揪出几条自认为做了其实没留痕的控制。标准文本给的是框架，能不能撑住现场，靠的是这种一遍一遍的笨功夫。希望帮到你。

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