ISO 27001的风险评估为什么难以落地？从资产识别到风险值的现实拆解

时间：2026-10-09浏览次数：35

这个问题在准备认证的企业里出现频率很高。风险评估在标准里只占一个条款，实际执行却常常拖住整个项目：资产清单编了三版还在改，威胁脆弱性分析写成空话，风险值算出来没人认。问题不在标准难，而在于企业习惯用合规思维做一件本该由业务判断驱动的事。下面按实际执行顺序拆开讲。

一、卡点在资产识别，根子在范围没定

资产识别做不下去，通常不是清单模板不好，而是范围没有确定。范围没定，边界就模糊，什么该进清单、什么可以排除，判断不了。

比较可行的做法是先从业务出发倒推。先把要认证的业务和服务列出来，再列出支撑这些业务的信息系统，再列出系统依赖的数据、主机、网络设备、机房和相关人员。这样得到的资产清单是围绕业务长的，不是凭空罗列的。范围外的资产，说明理由后可以排除，但客户或监管方在意的部分不建议排除。

另外，资产清单不必追求一次到位。可以按重要程度分批，先覆盖核心业务的资产，再逐批补充。关键是清单要有所有者、位置和重要性等级，并且有更新机制。

二、威胁与脆弱性容易写成套话

很多人把威胁写成黑客攻击、病毒、火灾，把脆弱性写成管理不严、意识不足。这样的表述无法支撑后续的风险判断，因为不同系统面临的同一威胁，实际条件差别很大。

改进方法是让分析贴近具体场景。举例来说，同样是数据泄露这个威胁，一套面向公网、权限靠手工维护、离职账号没有清理节奏的客户管理系统，与一套只在办公网访问、权限由统一身份平台管理、变更须审批的内部系统，脆弱性完全不同，风险等级也不应一致。

分析时可以从几个角度提问：资产暴露在哪里，谁能接触到，现有控制措施是什么，控制措施有没有被验证过，历史上有没有相似事件。问到这些，脆弱性就具体了。

三、影响与可能性要给判断依据

影响可以从业务中断时长、财务损失、法规后果、客户与声誉影响、人员影响几个维度评估。企业可以事先约定这些维度各自的取值标准，例如中断时长分档、法规后果按是否触发通报义务分档。

可能性可以参考历史事件频率、行业态势、控制措施的成熟度。要注意的是，可能性的判断不应只由信息技术部门给出，业务部门对业务中断的实际感受更有参考价值。

四、风险准则要提前定，不能边评边定

风险准则包括影响准则、可能性准则和风险接受准则。通俗说就是先把尺子造好：影响分几档、可能性分几档、组合后风险是几级、哪一级以上必须处置、谁来批准接受风险。

这一点如果没做到位，会出现两类麻烦。一是不同部门用不同标准评估，结果不可比；二是评到某个高风险时发现准则不合适，临时调整，导致前面评过的要重做。

五、风险处置要落到动作，而不是结论

处置方式有降低、保留、转移、规避四种。选择哪种，要有理由。选择降低的，要说明增加或加强哪些控制；选择保留的，要在准则允许范围内并取得批准；选择转移的，要说明通过什么方式转移；选择规避的，要说明业务如何调整。

处置计划要有责任部门或责任人、完成时间和验证方式。完成后需要有跟踪记录。审核时常见的追问是：这个措施真的执行了吗，怎么证明有效。

六、与适用性声明的衔接

风险评估的结果要落到适用性声明里。93项控制中，适用的要说明与哪些风险或合规要求相关，排除的要说清理由。声明中的实施状态要与风险处置计划的执行进度一致，不能一边写已实施、一边计划里还在推进。

七、几个让评估落地的具体建议

先定准则再评风险，避免反复。评估人员要覆盖业务、技术、人事、行政、法务等相关部门，由体系负责人统一组织。资产清单做成台账并纳入变更管理，新系统上线、系统下线、供应商更换时同步更新。风险评估按策划的周期或在重大变化时重新开展，形成惯例。评估结论要进入管理评审，让管理层看到风险分布与资源需求的对应关系。

如果企业本身缺少体系推进经验，可以借助外部顾问把方法与模板搭起来，但风险等级的具体判断仍要由企业自己作出，因为风险承受能力只有企业自己清楚。

27001 (2).png