简介：面向信息安全从业者、合规审计与咨询顾问的ISO/IEC 27002:2022中文试译稿，针对新版信息安全控制指南的落地理解与体系衔接需求，适合在建立、运行或审核信息安全管理体系时对照查阅。压缩包共1个PDF文件，约44.41MB，内容以标准正文与试译说明为主，包含序、引言、范围、术语定义、标准结构及组织控制等章节，便于按主题检索控制目标、控制措施与实施要点。已有351人学习下载，可作为理解2022版变化、梳理控制项与ISO/IEC 27001映射关系的参考材料。文档还涉及背景和语境、信息安全要求、确定控制、生命周期考虑因素及相关国际标准，并附译者说明与版本修订记录，有助于读者把握新版标准在网络安全、数据安全治理和管理方面的思路，用于内部培训、体系文件修订或控制措施自查时快速定位条款依据。

1. 一句话说清 ISO/IEC 27002：一份给全组织的「安全控制菜单」

装修过房子的人大概都见过两份截然不同的纸：一份是施工做法手册，防水刷几遍、电线用多粗、瓷砖留多宽的缝，全写得明明白白；另一份是验收单，上面只有合格与不合格两个格子。ISO/IEC 27002 就是信息安全领域的那本做法手册。它不负责发证书，也不命令你必须做什么，而是把「保护信息」这件听起来很虚的事，拆成九十多条能动手落地的控制措施，每条都写清楚目的是什么、具体怎么做、在什么条件下才需要考虑。

搞懂它的价值不在于背条款，而在于建立一套判断力：当外部要求、客户问卷、内部审计一起压过来时，你能一眼分辨哪些是「达标门槛」，哪些是「做法参考」。信息安全管理体系这个词听着唬人，落到实处其实就是在回答一个问题——我们打算用哪些手段，把哪些风险压到什么程度。27002 给的正是这份手段清单。

2. 为什么会有这份文件：控制、风险与一个可选武器库

2.1 控制到底是什么：不是买设备，而是把风险压到可接受

先把「控制」这个词从玄学里捞出来。它跟「控制欲」没关系，指的是任何能改变风险大小的手段：一道门禁、一条制度、一次培训、一份备份、一段代码里的输入校验，都算。安全领域习惯把风险拆成三个乘在一起的因子：威胁会不会来、你这儿有没有可被利用的薄弱点、真出事了损失多大。控制措施的作用点，就是中间那个「薄弱点」和最后那个「损失」。

拿小区防盗打个比方就很清楚。围墙和门禁是让贼不容易进来，这叫预防性控制；监控探头和巡逻是让进来的人被看见，这叫检测性控制；保险公司理赔和备用钥匙，是事情已经发生之后把损失兜回来，这叫纠正性控制。三类控制缺一不可，只装探头不装门，等于欢迎光临还全程录像。信息安全的控制也是同一个逻辑：备份属于纠正性，主要保的是「数据没了还能找回来」；日志和活动监视偏检测性，解决「出了事能不能还原现场」；访问控制、职责分离、安全编码偏预防性，尽量别让事情发生。

这里有个容易被忽略的点：控制是有成本的，而且成本不只是钱。多一道审批就多一次等待，多一条加密就多一次密钥管理的麻烦。所以真正专业的做法不是把所有控制都堆上去，而是先想清楚「我要防的是什么、我愿意为它付出多少不便」，再回头挑手段。这就是为什么同一份 27002，两家公司勾出来的清单能差出一半——不是谁抄错了，是两家的风险账本不一样。

2.2 27002 只给「怎么做」，不说「你必须做」

这份文件最容易被误读的地方，是把它当成强制性要求。它更像餐厅菜单：菜品、用料、做法、口味说明都写得清清楚楚，但点哪几道、点多少，取决于你今天几个人吃饭、预算多少、有没有忌口。标准里每条控制都带了「目的」和「实施指南」，意思是告诉你这道菜为什么这么配、火候怎么掌握，而不是逼你全点。

那谁来决定点哪些菜？答案是组织自己，依据是风险评估的结果和业务的实际需要。做完评估，把适用的控制挑出来，逐条写下「为什么选它」或者「为什么不选它」，这份记录在业内叫适用性声明。它是体系和清单之间的桥梁：清单是公共的，声明是个性化的。很多团队第一次做体系时最容易翻车的地方就在这儿——直接把九十多条全勾上「适用」，看起来很安全，实际上等于宣布「我们什么都做」，审计时一条证据都拿不出来。

提示：判断一条控制是否适用，问的不是「这条好不好」，而是「如果不做这条，我们哪个具体风险会变大」。答不上来，通常就是不适用，或者暂时优先级不够。

2.3 从旧版到 2022：为什么是重写而不是打补丁

2022 年这次更新不是小修小补，结构整个换了一副骨架。旧版的写法是把控制挂在若干「控制目标」下面，层层嵌套，条目又多又碎，找一条控制得先想它属于哪个大类。新版干脆砍掉中间层，直接按四个主题归类——组织、人员、物理、技术，93 条控制平铺在四个篮子裡，编号从 5 排到 8。找东西从「回忆目录树」变成「想想这事归谁管」，对新手友好得多。

更关键的变化是「属性」这套标签的引入。以前想筛出「所有跟检测有关的控制」，只能靠人肉通读；现在每条控制都贴了五类标签，按控制类型、保密性完整性可用性、网络安全概念、运行能力、安全域各打一遍，想怎么切就怎么切。这背后是环境变了：云服务、远程办公、供应链、隐私保护这些事在旧版里根本没有合适的位置，硬塞进去只会越塞越乱。新版还专门补了一批条目，像威胁情报、云服务的信息安全、ICT 供应链、数据遮盖、Web 过滤、安全编码，光看名字就知道是给这几年新出现的问题准备的。

换个角度理解这次重写：旧版像一本按章节编排的教科书，新版像一张打了多维标签的数据库表。前者适合从头读到尾，后者适合按需检索和交叉比对。对做落地的人来说，后者的实用性强得多，因为你很少需要「通读全部控制」，你更需要的是「把跟云端数据有关的条款一次捞干净」。

3. 93 条控制怎么排：四个主题的骨架

3.1 组织控制（37 条）：把安全写进制度和关系里

四个主题里最庞大的是组织控制，37 条，从信息安全策略、角色职责、职责分离，一路排到文件化的操作程序。这部分的共同点是：它们几乎都不是靠某个技术工具能解决的，得靠制度、流程和人之间的约定。放在最前面的 5.1 到 5.4 讲的是「谁来定规矩、谁负责、权力怎么分、管理层要不要真管」，等于给整个体系打地基。

中间一大段是资产和访问：资产清单、可接受使用、资产归还、信息分类、信息标签、信息传递、访问控制、身份管理、鉴别信息、访问权限。这组条目连起来其实是一条完整链路——先知道你有什么（清单），再定它能怎么用（可接受使用与分类），最后控制谁能碰它（身份、鉴别、权限）。很多团队上来就做权限梳理，却连资产清单都没有，结果权限收得再紧，也说不清到底保护了什么。

再往后是供应链和云：供方关系中的信息安全、供应商协议条款、ICT 供应链、供方服务的监视评审与变更、云服务的信息安全，五条连成一片。这是 2022 版特别用力的方向，因为现实中的事故越来越多不是自己机房出事，而是下游某个服务商出了问题。这一组控制要解决的是「别人的风险怎么变成我的责任」——把安全要求写进合同、定期看对方的实际表现、变更时重新评估。

事件管理和连续性占了另一块：事件管理的规划准备、事态评估与决策、应对、吸取教训、收集证据、中断期间的信息安全，加上 ICT 为业务连续性做好准备。这组条目的顺序本身就很有讲究，从「事前准备」到「事中判断」到「事后复盘」，最后还单独提了证据收集——因为很多事件最后会走到追责或法律程序，现场没保住，后面全是空谈。剩下的法律法规、知识产权、记录保护、PII 隐私、独立评审、合规性检查、文件化程序，则把体系跟外部世界接上了轨。

3.2 人员控制（8 条）与物理控制（14 条）

这两个主题条目少，但最容易被「技术流」团队跳过，然后在该出问题的地方出问题。人员控制只有 8 条：审查、雇佣条款和条件、意识教育与培训、纪律程序、雇佣关系终止或变更后的责任、保密或不披露协议、远程工作、报告信息安全事态。它覆盖的是一个人在一家公司的完整生命周期——进来之前查背景，进来时把安全责任写进合同，在岗期间反复教育，犯了事有明确的处理程序，走人的时候权限和责任一起收回。远程工作单独成条，是这几年最实际的变化：家里的网络、共享的桌面、孩子在旁边跑来跑去，都让「办公环境可控」这个前提不再成立。

物理控制 14 条，从物理安全周界、物理入口、办公室和设施保护、物理安全监视、抵御环境威胁，到安全区域内工作、清桌清屏、设备安置、场外资产、存储介质、支持性设施、布线安全、设备维护、设备的安全作废或再利用。这组条目的逻辑非常朴素：门要锁、人要管、纸要收、旧硬盘别直接扔。听起来像常识，但常识恰恰最容易失守——会议室白板上的架构图、打印机旁边没人取的合同、报废时没消磁的硬盘，都是经典事故现场。清桌清屏这条尤其值得单独拿出来说，它的成本几乎为零，收益却极直接。

3.3 技术控制（34 条）：从终端到代码

技术控制 34 条，是工程师最亲切的一块。开头几条管身份和权限：用户终端设备、特殊访问权、信息访问约束、获取源代码、安全身份认证。特殊访问权这条针对的是管理员账号——权限越大，越要单独管、单独审、单独限时。往后是运维日常：容量管理、防范恶意软件、技术漏洞管理、配置管理、信息删除、数据遮盖、防止数据泄漏、信息备份、设备冗余、日志、活动监视、时钟同步、特权实用程序、操作系统装软件。这一串基本就是运维值班表上那些事，只是标准把它们从「经验」提升成了「可检查的条目」。

时钟同步这条常被当成凑数的，其实相当关键：一旦出事要做时间线还原，几台机器的日志时间各差几分钟，整个因果链就断了，取证的人只能靠猜。日志和活动监视也是同理，前者是留证据，后者是主动看异常，两个不能互相替代。

网络与开发占了后半段：网络安全、网络服务的安全性、网络隔离、Web 过滤、密码学的使用、安全开发生命周期、应用程序安全要求、安全系统架构和工程原理、安全编码、开发和验收中的安全性测试、外包开发、开发测试生产环境分离、变更管理、测试信息、审计测试期间信息系统的保护。这一段把安全从「机房」推进到了「代码」：安全不能只在边界上拦，还得在设计和编码阶段就长出来，否则后期每修一个洞都要付一次昂贵的返工费。为了看清一条控制到底由哪些字段构成，可以把它按标准里的布局抽象成下面这样：

control: id: 8.13 # 控制编号，对应第 8 章技术控制 name: 信息备份 # 控制标题 statement: 按既定的备份策略，定期备份信息、软件和系统 # 控制陈述，一句话说做什么 purpose: 防止数据丢失 # 目的，回答“为什么值得做” attributes: control_type: 纠正性 # 出事之后把数据找回来 cia: [可用性] # 主要保障的是“用得上” capability: 技术 # 靠平台和工具落地 guidance: 备份范围、频率、保存位置、保留期限、恢复演练与加密要求 # 实施指南，落到怎么做

这份字段示意是把标准 4.3 节的控制布局做了简化，不是原文格式。id 和 name 负责定位，statement 是一句话的控制要求，purpose 解释了它防的是什么，attributes 是 2022 版新增的多维标签，guidance 才是真正的操作空间——备份多久做一次、存哪儿、留多久、要不要加密、多久做一次恢复演练，全在这一栏里由组织自己填。实际使用中，最后这一栏填得越具体，落地时越不容易糊弄过去；只写「定期备份」四个字的，通常等于没写。

4. 属性：2022 版最值得先搞懂的新东西

4.1 五种属性分别回答什么问题

属性是这版最容易被跳过、也最值得先弄明白的设计。它给每条控制贴上五类标签，每类回答一个不同的问题，合起来就是一张可以任意维度切片的表。

先看控制类型。预防性控制是「别让它发生」，检测性控制是「发生了要看得见」，纠正性控制是「发生了要能收拾」。三条腿缺一条，体系就是瘸的。很多组织在预防上砸钱最狠，防火墙、加密、权限审批一样不落，检测和纠正却近乎空白，结果是被入侵了半年才发现，发现之后也没有可回滚的备份。

信息安全属性这一栏，是把控制挂回保密性、完整性、可用性这三根老柱子上。有意思的是，很多控制并不只服务一个目标：访问控制主要保保密性，信息备份主要保可用性，而日志和变更管理往往同时服务于完整性和可用性。看清这一点，讨论「这条控制值不值得做」时就能直接对上业务语言——业务怕的是数据泄露，还是怕系统停摆，答案不同，优先级就不同。

网络安全概念这一栏最有「翻译」价值，用的是识别、保护、检测、响应、恢复这套五段式节奏。它把九十多条控制摊到一条时间线上：出事之前你在识别资产和风险，出事当下你在保护、检测、响应，事后你在恢复。安全域那一栏则更偏治理视角，把控制按治理与生态、保护、防御、韧性与改进归堆，方便管理层看「我们在哪个层面投入不足」。运行能力最简单：靠技术、靠人、还是靠制度。

4.2 一个例子：给「信息备份」贴满标签

拿 8.13 信息备份走一遍。控制类型是纠正性，因为它不阻止数据丢，只在丢了之后把数据找回来；信息安全属性主要落在可用性上，顺带也能防篡改（前提是备份介质本身受保护）；网络安全概念这一栏跨了保护和恢复两段；运行能力偏技术，但备份策略的制定和演练的组织又离不开人；安全域大致归在韧性与改进。五个标签贴完，这条控制在整个体系里的位置就清楚了：它是一个兜底角色，位置靠后，但一旦缺失，前面所有预防措施的价值都会打折。

再看一条反差大的：6.3 信息安全意识、教育和培训。控制类型是预防性，信息安全属性三项都沾一点，网络安全概念落在保护段，运行能力明确是人员，安全域偏治理。把这两条并排放，你会发现它们的标签几乎不重叠——这正是属性的用处，它让「一条控制和一个组织」之间的匹配关系变得可计算、可讨论。

4.3 属性的用处与误用：筛选不等于取舍

属性最直接的用处是筛选。想找「所有检测性控制」来补监控短板，一筛就出来了；想找「所有靠人实现的控制」来评估培训预算，也是一筛就出来；想跟别的管理框架对齐，把网络安全概念那一栏当翻译层，两边的词就能对上话。对写材料的人来说，这比按章节顺序硬读省太多力气。

但属性有两个坑。第一个坑是把标签当结论：一条控制被标成「预防性」，不代表它只做预防，标签是主要倾向，不是全部分工。第二个坑更常见——以为贴了标签就等于做了取舍。属性只是描述工具，它不告诉你哪条该做哪条不该做。真正决定取舍的仍然是风险评估：你的资产值多少、威胁有多现实、现有薄弱点在哪。见过不少团队把属性矩阵做得漂漂亮亮，一到要说明「为什么这条不适用」就哑口无言，问题就出在把检索工具当成了决策工具。

注意：属性的取值是标准方给的通用分类，落到具体组织时，同一条控制可能因为业务场景不同而落在不同侧重上。标签可以照抄，理由必须自己写。

5. 常见易混与误区：这几组概念最容易搞反

5.1 27002 和 27001：做法手册与达标要求

易混点在于两个编号长得像、名字也像，很多人以为是一份文件的两个版本。为什么会混：它们确实是一对搭档，通常一起出现，讲的内容也高度相关。怎么区分：27001 是「要求」，写的是你必须建立并运行一套管理体系，包括风险评估、风险处置、适用性声明、内部审核、管理评审这些动作，是可以被认证的标准；27002 是「指南」，写的是具体有哪些控制手段、每条怎么做，本身不构成认证依据。一句话记：27001 考你有没有体系和证据，27002 教你怎么选手段。做体系的人两本都要翻，但翻的目的完全不同——一本是对表，一本是查菜谱。

5.2 控制目标退场：目标和措施不是一回事

旧版有一个中间层叫「控制目标」，每条控制都挂在一个目标下，比如「访问控制的目标是限制对信息和设施的访问」。2022 版删掉了这一层，直接给控制条目，改用属性和主题来组织。易混点在于：很多人还在用老话术，把某条控制说成「控制目标」。为什么会混：旧文档、旧培训材料、旧模板里全是这个说法，习惯很难改。怎么区分：目标是「我要达到什么状态」，措施是「我用什么手段达到」，前者是判断标准，后者是动作。现在标准里每条控制自带一个「目的」字段，功能上接替了当年控制目标的位置，但它挂在具体控制下面，不再单独成层。写材料时把两者混用，最直接的后果是适用性声明里列的全是目标而不是可执行的动作，审起来没法验证。

5.3 通用菜单与专项菜谱：别拿 27002 当万能答案

易混点是把 27002 当成安全领域的唯一参考，遇到云、隐私、工业场景也硬套。为什么会混：它覆盖面确实广，四个主题 93 条看着很全，容易产生「一本通」的错觉。怎么区分：27002 是通用控制清单，具体领域通常有更细的专项标准，云服务、隐私保护、行业特定场景各有各的补充要求。正确姿势是先拿 27002 搭骨架，再按业务所处领域补专项条款，而不是反过来。就像装修做法手册再全，也不会有「手术室净化工程」的施工细节，那是另一本规范的事。

5.4 拿到指南不等于合规，更不等于安全

易混点是把「有这份文件」当成「问题解决了」。为什么会混：标准本身有权威感，中文版一到手，心理上就先踏实了一半。怎么区分：合规是证据问题，安全是效果问题，两者都不是文档能自动产生的。真正决定成败的是三件事——有没有做风险评估、有没有把选中的控制落成可检查的动作、有没有留下能证明它一直在运行的记录。见过太多团队把标准打印出来放进文件夹，权限该共享还共享，离职账号该留着还留着。文档的价值在于统一语言、提供清单、支撑判断，它不会替任何人值班。

6. 什么时候该翻它，什么时候别指望它

判断标准其实很简单：当你需要「选手段」的时候，它有用；当你需要「拿结论」的时候，它帮不上忙。

举个具体例子。某公司三十来人，第一次认真做体系，负责人一开始的想法是把 93 条全勾上，觉得这样最保险。真到写证据的时候傻了：一半条目根本找不到对应动作，比如 ICT 供应链那几条，公司压根没有像样的供应商管理流程；再比如物理安全监视，办公区是合租的，连门口摄像头都不归自己管。后来改成先做资产清单和一轮务实的风险评估，从 93 条里挑出四十来条真正对症的，每条都写清楚「选的理由」或者「暂不适用的理由」，剩下的列入后续计划。工作量少了一半，审计时反而顺利——因为每一条都能指出证据在哪个文件夹。

我自己的血泪经验是：永远不要在没做风险评估之前打开这份清单开始勾选。有那么一次，我在项目初期图省事，先把控制清单拉了一遍，勾得挺齐，等到风险评估做完，发现真正的大风险在数据导出和外包开发上，而那两块当时只勾了两条最泛的。返工的时候才明白，清单是给风险配药的，顺序反了，配出来的东西看着齐全，实际上没打到点上。从那以后我每次做适用性声明，都强制先过一遍风险清单，再翻控制条目，勾一条写一条理由，写不出理由的就先空着。希望帮到你。

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