ISMS风险评估怎么做｜从信息资产梳理到适用性声明的6个步骤

风险评估在ISO/IEC 27001中的位置

在ISMS中，风险评估是连接"保护什么"与"采用哪些控制措施"的唯一桥梁。若先定控制措施再补理由，审核时一定会被追问依据。标准的要求可归纳为以下四点。

• 第6.1.2条（信息安全风险评估） — 制定风险接受准则与实施评估的准则，确保过程能产生一致、有效且可比较的结果。包含风险识别、分析、评价，以及识别风险责任人。
• 第6.1.3条（信息安全风险处置） — 选择处置方案，确定必要的控制措施，与附录A比对确认无遗漏，并编制适用性声明（SoA）。风险处置计划与剩余风险还需取得风险责任人的批准。
• 第8.2 / 8.3条 — 按策划的时间间隔，以及在发生重大变更时实施评估，执行风险处置计划，并将结果保留为形成文件的信息。
• 附录A — 93项控制措施的参考清单。它不是"从中挑选"的菜单，而是用于比对已确定控制措施有无遗漏的对照表。

整体流程可参见ISO27001认证取得的推进方式。通常应在确定适用范围之后立即启动，并早于控制措施的实施。

步骤1：先定义风险准则（接受准则与评价准则）

最先确定的不是资产而是准则。没有准则就开始列资产，不同负责人的评分会出现偏差，最后只能全部重打分。需要确定四项：可能性尺度、影响程度尺度、评分方法、风险接受准则。中小规模组织采用三级即可运行。

影响程度以保密性、完整性、可用性（CIA）受损时的业务影响来衡量。在准则文件中写入判断示例，例如"客户数据外泄属重大（3）"，可避免评分漂移。风险接受准则同样要用数值明确写出，例如"评分3分及以下予以接受，4分及以上需考虑处置"。

步骤2：梳理信息资产并建立资产台账

接下来梳理适用范围内的信息资产。对象不仅是数据本身，还包括承载与处理数据的系统，以及相关的人员和场所。台账至少应包含以下字段。

颗粒度是成败的分水岭。按单个文件统计会达到数千条而无法维护；笼统写成"内部系统"又太粗，无法落到控制措施。建议以业务系统、数据库、共享文件夹为单位，100人以内规模通常在50～150条之间。资产台账也是认证所需文件之一，与ISMS所需文件清单一并整理可避免重复劳动。

步骤3：识别威胁与脆弱性（基于资产与基于事件）

风险识别大体有两种方法，ISO/IEC 27001:2022 并未强制其一。实操中并用更为现实。

• 基于资产的方法 — 针对每项资产，将"威胁（可能发生什么）"与"脆弱性（为何可能发生）"组合导出风险。例如：客户主数据 × 权限配置错误 × 离职人员账号未清理 → 非授权查阅。覆盖性强，但条目数容易膨胀。
• 基于事件（情景）的方法 — 从"勒索软件导致核心系统停摆"等可能发生的事件出发描述风险。条目较少、便于向管理层说明，但需另备核对清单以确认有无遗漏。
• 并用的做法 — 以资产台账保证覆盖性，再将影响较大的事件（供应链、内部违规、灾害、云服务商故障）作为独立情景补充。

此环节须为每项风险指定风险责任人。标准要求的是风险的责任人而非资产的所有者，即决定处置方针、批准剩余风险的角色，实务中通常为部门负责人层级。

步骤4・5：通过风险分析与评价确定优先级

使用步骤1确定的尺度，为每项风险赋予可能性与影响程度并计算评分。分析时原则上应评价现有控制措施发挥作用的状态（现状风险）。若按完全没有对策来评，所有条目都会变成最高风险，无法排出优先级。

评价环节将评分与接受准则比对，筛选出需要处置的风险。评分相同时，按是否存在法规与合同要求、影响是否波及业务连续性、处置成本是否相称的顺序判断，最便于说明。至此形成的记录即风险评估表。

步骤6：风险处置的四种方案与附录A控制措施的选择

对判定需要处置的风险，从以下四种方案中选择方针。不必全部填成"降低"，重要的是选择接受或转移的理由有据可查。

适用性声明（SoA）与风险处置计划

方针确定后，确定必要的控制措施，并与附录A的93项控制措施比对确认有无遗漏。在此基础上编制适用性声明（SoA），记载采用的控制措施及其依据、实施状况，以及不采用的控制措施的排除理由。写明"不适用"本身没有问题，关键是理由与风险评估结果保持一致。

1. 逐项确定风险处置方针（降低、规避、转移、接受）
2. 对选择降低的风险，具体确定所需的控制措施
3. 将已确定的控制措施与附录A比对，确认有无遗漏领域
4. 在适用性声明（SoA）中记载采用的控制措施、依据、实施状况与排除理由
5. 在风险处置计划中落实实施事项、责任人、期限与所需资源
6. 测算剩余风险，连同风险处置计划一并取得风险责任人的批准

剩余风险的批准与复审频次

实施控制措施后仍然存在的风险即剩余风险。需重新评价，确认处于接受准则范围内，并留存风险责任人的批准记录。未取得批准即进入运行，是较常见的问题点。复审应按每年至少一次有计划地进行，此外在引入新系统、办公场所迁移、发生重大事件、更换外包方时随时重新评价。整体投入可参见ISMS认证取得的费用。

常见误区与实操要点

• 资产列得过多 — 按文件为单位超过数百条后，每年一次的复审就转不动了。以系统、数据库、共享文件夹为单位归并更为现实。
• 准则含糊导致评分漂移 — 未写明"影响程度：中"的判断示例，次年换人后同一资产的评分就会改变。准则文件务必附上判断示例。
• SoA与风险评估表不一致 — SoA中标为"采用"的控制措施，在处置计划中却未与任何风险关联。二者应可相互检索。
• 风险责任人由经办人担任 — 让没有批准权限的经办人担任责任人，剩余风险的批准会流于形式。应指派具有决策权的岗位。

用工具管理台账与矩阵

以上产出共有四项：资产台账、风险评估表、SoA、风险处置计划，且相互引用。用Excel也能起步，但资产超过100条后，就会出现台账更新未反映到SoA、多人同时编辑导致版本分叉、缺少变更履历而无法说明何时由谁改了评分等问题。

将四者作为同一份数据联通，并自动留存变更履历与批准记录，每年一次的复审就能从全面盘点变为核对差异。Riscala AI for ISMS 正是按这种形态提供管理机制。若想先确认本公司推进到了哪一步，可从ISMS现状自查开始梳理。

本文仅供一般信息参考，不保证任何审核结果或认证获取。制度与费用可能变化，请向认证机构确认最新信息。