一、ISO/IEC 27001:2022 5.3 标准原文

二、条款解读说明

2.1 为什么5.3经常被低估

不少组织认为，已有IT部门、安全部门和业务部门，自然就已经分工明确。实际上，信息安全中的很多关键动作跨越多条管理线，例如账号开通涉及HR、直属主管、系统管理员和资产负责人，供应商管理涉及采购、法务、业务和安全，事件响应涉及IT、法务、品牌、公关、客服和管理层。如果不把职责、权限和升级路径写清，平时可能看不出来，一旦出现审计、投诉或安全事件，职责边界就会迅速混乱。

5.3关注的不是组织架构图本身，而是角色职责是否真实存在于流程中。也就是说，文件里写某岗位“负责信息安全”没有意义，关键在于该岗位是否拥有相应权限、是否知道何时介入、是否能获取所需信息、是否承担明确输出。没有权限的责任只是口号，没有责任的权限则会形成失控。

2.2 关键角色与职责逻辑

2.3 权责清晰比“设不设CISO”更重要

很多企业关心是否必须设独立安全部门或CISO岗位。标准并没有强制规定具体组织形式，真正重要的是职责清晰、权限匹配、接口明确。小型企业可以由一名兼任负责人推动体系，大型企业则可能需要专门团队和分层角色。不论结构如何，关键都在于：谁有权批准例外、谁负责风险评估、谁维护资产清单、谁推动事件复盘、谁决定整改优先级，这些问题必须清晰可答。

三、实施要点

3.1 先识别关键安全过程，再分配职责

• 围绕风险评估、访问控制、变更管理、供应商管理、事件响应、培训和审核等关键过程进行职责拆分。
• 避免先按部门拍脑袋分工，再发现关键接口没人负责。
• 每个过程至少明确发起、审批、执行、监督和升级角色。

3.2 用RACI矩阵把责任说清楚

• 对高频跨部门活动建立RACI矩阵，明确谁负责、谁批准、谁参与、谁被告知。
• 对高风险事项增加升级路径，例如超过时限未整改自动提交管理层。
• 矩阵应与流程和系统审批规则保持一致。

3.3 让职责与权限匹配

• 如果要求安全负责人推动整改，就要赋予其升级和协调机制，而不是只负责任何结果却没有推动手段。
• 如果要求业务负责人承担数据和风险责任，就要让其参与审批和风险接受，而不是只被动知会。
• 避免出现“权力在A，责任在B”的结构性矛盾。

3.4 做好职责沟通和培训

• 职责文件不能只存档，应进入岗位说明、流程培训和入岗培训。
• 对关键岗位如系统管理员、资产负责人、项目经理、采购经理开展专题培训。
• 在访谈中验证相关人员是否知道自己在ISMS中的具体责任。

3.5 发生变化时及时更新职责

• 组织重组、系统上云、引入外包、项目模式变化后，应及时调整职责分工。
• 职责更新应同步反映到流程、权限和审批矩阵中。
• 避免文件已改，系统和执行仍按旧方式运行。

四、常用工具与实施方法

五、典型案例

案例一：账号治理因职责不清长期失控

1. 背景：员工离职后账号回收常延迟，系统中残留大量历史权限。
2. 问题：HR以为IT会处理，IT以为直属主管会提单，业务负责人则没有被纳入流程。
3. 5.3动作：重构入离职RACI，明确HR发起、直属主管确认、IT执行、资产负责人复核、安全团队监控。
4. 结果：账号回收时效明显改善，历史权限积压减少。
5. 启示：很多安全漏洞背后其实是职责链断裂。

案例二：供应商管理由“采购问题”升级为“跨部门责任”

1. 背景：多个外包供应商接入内部系统，但安全条款落实不一致。
2. 问题：采购签合同，IT开权限，业务推动上线，安全团队最后才知道。
3. 5.3动作：明确采购负责准入发起和合同管理，业务负责需求合理性，安全负责审查，IT负责开通和回收，法务负责条款把关。
4. 结果：第三方接入流程更可控，补救成本下降。
5. 启示：安全职责从来不是单一部门可以独立承担的。

案例三：安全事件响应中的指挥权重建

1. 背景：企业发生异常访问事件时，多个团队同时行动，信息混乱。
2. 问题：没人明确拥有指挥权和对外沟通权限。
3. 5.3动作：在事件响应机制中明确事件经理、技术负责人、法务、公关和管理层各自权限与升级路径。
4. 结果：响应节奏更清晰，内部协同和外部沟通都更稳定。
5. 启示：职责清晰是应急成功的前提条件之一。

六、成文信息管理要求

5.3要求职责和权限得到分配和沟通，因此组织应保留既能证明职责设计，又能证明职责已被执行和理解的证据。只有组织架构图通常是不够的。

七、常见误区及踩坑提醒