波仔
🛡️ 第六章 组织机构的安全防范对策
📄 一句话概括

ISMS 的核心不是买什么产品，而是把【计划—执行—检查—改进】做成一个年复一年转下去的循环；ISO/IEC 27001 的价值在于它把这个循环写成了可审计的条款，并用附录 A 的 93 项控制给它配了一份清单。

📝 本节和前面几节的关系

6-1 定下了方针，这一节要解决的是【方针怎么落地、怎么被检查、怎么持续改进】。 它和 1-7 那条思路是同一条线：安全管理从来不是【一次做到最好】，而是在成本、便利、安全之间反复调整——PDCA 就是这个【反复调整】被制度化之后的样子。 后面几节都会挂在这个循环上：6-3 是 Check，6-8 是 Plan，6-5 属于 Do 里的应急部分。

一、PDCA 与标准条款的对应关系

ISO/IEC 27001:2022 的正文条款 4 到 10，正好可以按 PDCA 四阶段分组。记住这个映射的好处是：读标准时你就知道自己在读循环的哪一段：

阶段 对应条款 要留下的证据
Plan 4 组织环境 / 5 领导作用 方针、范围说明、角色职责文件
Plan 6 规划 / 7 支持 风险评估报告、风险处置计划、培训记录
Do 8 运行 控制措施实施记录、运行与监控日志
Check 9 绩效评价 内审报告、管理评审报告、指标数据
Act 10 改进 不符合项清单、纠正措施、改进记录

从这张表能看出一个设计意图：条款 4 和 5 被放在 Plan 的最前面，而不是从【做什么控制】开始。先讲组织的处境（4）和领导层的责任（5），再讲具体规划（6、7）——这个顺序是在明确一件事：安全管理的第一推动力来自管理层，而不是来自技术部门。

另一个细节：【要留下的证据】这一列才是审核现场真正看的。标准不问你【做得怎么样】，它问你【能不能证明你做了】——这也是为什么 6-3 会把【台账与记录】单列为一类产出。

二、附录 A：从 114 项 14 个域，到 93 项 4 个主题

2013 版的附录 A 有 114 项控制，分在 14 个域里；2022 版重构为 93 项、4 个主题：

37 + 8 + 14 + 34 = 93。这个算术值得亲手验一遍，因为它同时说明了一件反直觉的事：控制项从 114 减到 93，覆盖面反而更宽了。减的原因不是删控制，而是① 合并重复项、② 更新过时表述、③ 把散落的同类项归到一个主题下；增的原因是补进了云、隐私、数据泄漏、Web 过滤、安全编码这些 2013 年还不突出的东西。

这两个数字合起来看，才是这个标准真正的变化：它不是【变松了】，而是把力气从【铺得广】转到了【管得住】。

三、11 项全新控制：标准是跟着事故走的

2022 版有 11 项是 2013 版完全没有的。把这 11 项排在一起看，几乎就是过去十年事故类型的一张清单：

A.5.7  威胁情报                 A.8.9  配置管理
A.5.23 使用云服务的信息安全     A.8.10 信息删除
A.5.30 ICT 业务连续性准备       A.8.11 数据脱敏
A.7.4  物理安全监控             A.8.12 数据防泄漏
                                A.8.16 监控活动
                                A.8.23 Web 过滤
                                A.8.28 安全编码

云服务（A.5.23）对应的是数据和工作负载整体迁到云上；配置管理（A.8.9）对应的是【云配置错误】成了主要泄露成因（6-13 里有 2026 年的数据）；数据脱敏与防泄漏（A.8.11、A.8.12）对应的是个人信息合规与内部泄漏（6-14）；Web 过滤（A.8.23）对应的是访问不当内容（6-9）；安全编码（A.8.28）对应的是漏洞在源头而非在运行时就该被处理掉（4-11）。

注意到没有：新的 11 项里，有 8 项对应着本章后面的某一节。这不是巧合——标准修订的方向，就是把【出过事的地方】变成【必须写进清单的地方】。

四、动手 Demo：校验 93 项，并用转版日期卡一次证书

# 节选自本节 Demo 脚本 d2() 的两段：校验 93 项、按版本与日期判断证书有效性
doms = [("组织控制", "A.5", 37), ("人员控制", "A.6", 8),
        ("物理控制", "A.7", 14), ("技术控制", "A.8", 34)]
tot = sum(n for _, _, n in doms)                       # 93
assert tot == 37 + 8 + 14 + 34                         # 校验一遍，防止抄错

certs = [("甲公司", "2026-03-31", "2013 版，转版未完成"),
         ("乙公司", "2028-09-14", "2022 版，2025-09-15 换发"),
         ("丙公司", "2029-01-19", "2022 版，2026-01-20 首次认证")]
today = date(2026, 10, 9)
for name, exp, note in certs:
    left = (date(*map(int, exp.split("-"))) - today).days
    if note.startswith("2013"):
        why = "已于 2025-11-01 作废"                    # 转版窗口已关闭
    elif left <= 0:
        why = "已过期"
    else:
        why = "有效，还剩 %d 天" % left

实跑输出：

二、附录 A：从 114 项 14 个域，重构为 93 项 4 个主题
  主题                  编号    项数    占比
  组织控制              A.5     37      39.8%
  人员控制              A.6     8       8.6%
  物理控制              A.7     14      15.1%
  技术控制              A.8     34      36.6%
  合计                  A.5~A.8   93      100.0%
  → 校验：37 + 8 + 14 + 34 = 93，与 93 一致
  → 114 项压到 93 项：不是删控制，而是把重复的合并、把过时的更新、
     把散落的同类项归到一个主题下。控制项变少，覆盖面反而更宽。

四、转版检查器：2025-10-31 之后只认 2022 版证书
  依据 IAF MD 26，ISO/IEC 27001:2013 版证书的转版截止日为 2025-10-31。
  组织        原证书到期日    现在的状态
  甲公司      2026-03-31      2013 版，转版未完成  → 已于 2025-11-01 作废
  乙公司      2028-09-14      2022 版，2025-09-15 换发  → 有效，还剩 706 天
  丙公司      2029-01-19      2022 版，2026-01-20 首次认证  → 有效，还剩 833 天
  → 到期日在未来，不等于证书有效：如果 2026-10-09 手里仍是 2013 版，
     那它在 2025-11-01 就已经作废了。

读这个输出：

五、⚠️ 2026 现状

30 秒实验

今天做两个动作，各 15 秒：

  1. 数一下上面那 11 项全新控制里，有几项对应着本章后面的小节。 数出来是 8 项左右——这个比例说明一件事：新标准里增加的内容，基本都能在现实事故里找到出处。以后看到标准更新，可以先问【这次是出了什么事】。
  2. 随手拿起一份你见过的体系证书（公司墙上的、供应商发的、招聘信息里写的），看两个位置：版本号（是 2013 还是 2022）和有效期。 如果只写有效期不写版本，那这份材料在 2026 年已经不足以说明问题。

这一节要带走的一句是：ISMS 不是一套产品，而是一个循环——它的价值不在某一年做到多少分，而在于【检查—改进】这两步有没有真的转起来；标准条款只是把这个循环的每一步都变成可被追问的记录。

常见误区

  1. 错误：拿到了 ISO 27001 证书，就说明公司安全水平高。——纠正：证书证明的是【管理体系按照标准运行过并被审核过】，不是【没有风险】。它更像驾照而不是体检报告：驾照说明你会开车、流程合规，不说明你不会出事故。具体来说有三点要知道：① 认证覆盖的是声明的范围，范围外的东西不在其中（审核报告里的范围定义要看清楚）；② 认证是周期性的（每年监督审核、三年复评），两次审核之间体系可能已经空转；③ 附录 A 的 93 项里，被【适用性声明】排除掉的那些，等于没做——看证书不如看适用性声明和最近一次的不符合项清单。

  2. 错误：控制项少了（114 → 93），说明要求变松了。——纠正：正好相反，是密度变高了。合并的是重复项（同一件事在多个域里各写一遍），新增的是过去十年真正出过事的地方（云、隐私、数据泄漏、Web 过滤、安全编码）。另一个变化是结构：旧版按 14 个域平铺，新版按 4 个主题归类，并且把【组织控制】提到最大的一块（37 项）——这个结构调整本身就在说：安全管理的重心在组织层面，不在技术层面。 对做落地的人来说，这意味着【再买一台设备就完事】的思路越来越不合规。

  3. 错误：ISO 27001 和等级保护是一回事，做了等保就不用做 27001。——纠正：两者的性质、依据和用途都不同。等级保护是国家强制要求的合规基线（依据 GB/T 22239-2019 等），按系统定级、备案、测评、整改的路径推进；ISO/IEC 27001 是自愿性的国际管理体系认证，证明组织的管理体系符合国际标准，主要用途是对客户、合作伙伴与市场的信任凭据。一个常见的误区是反问【既然 27001 更全面，那等保能不能不做】——不能：等保是法定要求，与安全水平高低无关；反过来，过了等保也不等于管理体系达到了 27001 的要求。两者是两条路上的两个证明，重叠但不互相覆盖。

  4. 错误：审核就是查文档，把资料准备好就能过。——纠正：这正是 2026 年新规则要堵的口。新版认证规则明确要求审核人员实地到现场、并提交完整的体系运行台账、内审报告与管理评审报告——这些材料的特点是【必须平时一天一天攒出来】，补不出来。举个具体例子：管理评审要求最高管理者参与并形成记录，如果这一年只开过一次会而且还缺记录，那么审核前两周是补不出一整年的运行痕迹的。判断自己会不会在审核时被卡，方法很简单：把最近三次内审的不符合项清单翻出来，看有几条真正闭环了——闭环率是最诚实的指标。

自测三问（点开对答案） 1. 为什么说控制项从 114 项减到 93 项，覆盖面反而更宽了？ —— 因为这次修订做的是**重新划分**，不是**删减要求**。**具体有三类动作**：① **合并**——同一件事过去在多个域里各写一条（比如【日志】和【监控】分散在不同域），现在归到一处，算下来项数少了；② **更新**——把表述过时、与当下技术脱节的项目改写或吸收进新项；③ **归类**——14 个域按性质收拢成 4 个主题（组织、人员、物理、技术）。**同时新增了 11 项 2013 年完全没有的内容**，主要落在云服务、隐私与数据保护、上网控制、安全编码这些方向。**所以【项数变少】是皮相，【管的东西更贴当下】才是实在**。**一个直接的判断方法**：**如果你所在的行业在 2013 年之后出过引起关注的安全事件，去看看新版附录 A 里有没有对应的控制项——大概率有。** 2. PDCA 里，Check 阶段最容易做形式的地方在哪？ —— **最容易被做形式的是【Check 的结果没有回流到 Plan】**。**表现是**：内审做了、报告出了、不符合项列了，**但下一年度的风险处置计划里，看不到任何针对这些不符合项的条款**。**换句话说，循环在 Check 之后断了，只剩下 P→D→C，转不回来**。**第二个容易形式化的地方是【指标数据】**：**如果指标只统计【做了多少次培训、发了多少份通知】这类过程量，而不统计【钓鱼点击率、漏洞修复中位天数、备份恢复成功率】这类结果量**，**那么 Check 出来的结论一定是【情况良好】，因为它测的是投入不是效果**。**这一节后面 6-3 会给出一组可用的指标，可以对照检查自己的表是不是都落在过程量上。** 3. 附录 A 的适用性声明（SoA）里可以排除某些控制项，这意味着什么？ —— 意味着**【不适用】必须由组织自己论证，而且这份论证要被审核**。**排除不是【我不想做就不做】**：**你需要在适用性声明里逐项写明【这项控制为什么对本组织不适用】**（例如：组织没有任何纸质归档，那么某条关于纸质介质处置的控制就可以说明为不适用）。**风险在于两点**：① **论证不充分会被开不符合项**——比如声称【我们不做云服务】但实际用了 SaaS，那 A.5.23 就排除不掉；② **排除的项会在下一次业务变化时变成盲区**——**去年不用的云，今年用了，但适用性声明没更新**。**所以看一份证书的含金量，最有效的方法是翻它的适用性声明：排除项越多、理由越含糊，说明体系覆盖的实际范围越小。**

相关笔记