一、ISO/IEC 27001:2022 4.2 标准原文
ISO/IEC 27001:2022 4.2 理解相关方的需求和期望
条款要求：组织应识别与信息安全管理体系有关的相关方及其相关要求，并确定这些要求中哪些将通过ISMS予以应对。
在ISO 27001语境下，相关方不只是客户和监管机构，还包括股东、员工、外包服务商、云平台、支付机构、合作伙伴、审计机构以及在事件发生时会直接承受影响的数据主体。
条款要求：组织应识别与信息安全管理体系有关的相关方及其相关要求，并确定这些要求中哪些将通过ISMS予以应对。
在ISO 27001语境下，相关方不只是客户和监管机构，还包括股东、员工、外包服务商、云平台、支付机构、合作伙伴、审计机构以及在事件发生时会直接承受影响的数据主体。
提示：完整原文请参阅 ISO/IEC 27001:2022 正式文本
引用：4.2回答的是“我们必须对谁负责、必须满足哪些安全要求、哪些要求需要进入体系运行”。
二、条款解读说明
2.1 为什么4.2比很多组织理解得更复杂
许多组织把4.2等同于“客户要求识别”，这在ISO 9001里已经不够，在ISO 27001里则明显失真。信息安全管理牵涉合规、合同、运营、技术和声誉多个层面，不同相关方的要求往往不是线性的。例如，客户要求可能体现在安全问卷、主协议、DPA、审计条款中；监管要求可能体现在法律法规、行业规则、备案要求和处罚尺度中；员工与供应商的要求，则可能通过权限边界、保密义务、设备使用规则和离职交接体现出来。
4.2的难点在于“筛选和转化”。不是所有相关方的意见都必须进入ISMS，也不是所有期望都必须承诺满足。组织需要判断哪些要求与信息安全有关、哪些具有约束性、哪些会影响风险接受标准和控制选择、哪些应纳入目标、流程和成文信息。做不好这一步，体系就会陷入两个极端：要么范围过宽、承诺过度；要么遗漏关键合规和客户要求。
2.2 关键要素解构
| 要素 | 具体含义 | 典型来源 | 管理动作 |
|---|---|---|---|
| 相关方识别 | 识别受ISMS影响或能够影响ISMS的组织和个人 | 客户、监管机构、员工、供应商、股东、合作伙伴 | 形成相关方清单 |
| 要求识别 | 识别其对信息安全的明示和隐含要求 | 法律、合同、审计问卷、SLA、岗位制度 | 形成要求台账 |
| 适用性判定 | 判断哪些要求进入ISMS承诺范围 | 风险、合规、经营决策 | 标注“纳入/观察/不纳入” |
| 持续更新 | 跟踪相关方变化和要求变化 | 新增客户、供应商变更、法规更新、业务扩张 | 版本更新与责任分配 |
2.3 4.2的审核关注点
审核员通常不会满足于看到一张“相关方识别表”，而会继续追问：客户提出的数据删除时限有没有落到流程里？监管要求是不是只停留在法务认知，没有转化为操作要求？供应商访问内网的约束是否进入合同和账户管理规则？因此，4.2最关键的不是清单本身，而是组织能否证明识别出的关键要求已经被吸收到体系中，或者有明确理由说明暂不纳入。
注意：4.2中的“需求和期望”并不意味着全部照单全收。组织的责任是识别、判断并明确其处理方式，而不是无限扩张承诺边界。
三、实施要点
3.1 先分层识别相关方
- 第一层识别具有法律或合同约束力的相关方，如监管机构、重要客户、关键供应商。
- 第二层识别影响运营连续性和事件处置的相关方，如云服务商、托管方、外包团队、审计机构。
- 第三层识别影响品牌信任和内部执行的相关方，如员工、候选人、用户、股东和社会公众。
3.2 用“要求分类法”提高可操作性
- 将要求分为法律法规要求、合同要求、行业规则要求、内部治理要求和市场期望要求。
- 再按强制性、重要性、适用范围和验证方式做二次分类。
- 这样后续更容易决定哪些进入控制设计，哪些进入沟通或例外管理。
3.3 识别隐含要求而不只盯显性条款
- 客户即使没有明确写“最小权限原则”，也可能通过审计问卷、日志保留要求和第三方评估间接提出高标准要求。
- 数据主体虽然通常不是合同相对方，但其隐私保护需求会通过法律和舆情压力转化为组织必须满足的要求。
- 股东和董事会对重大事件零容忍，实际上会影响组织对高风险控制的投资决策。
3.4 明确要求的承接路径
- 对于法律法规要求，应落到合规清单、制度条款、流程控制点和检查频率。
- 对于客户合同要求，应落到交付流程、权限控制、日志留存、事件通知和供应商管理。
- 对于内部治理要求，应落到岗位职责、培训计划、奖惩机制和管理评审。
3.5 让4.2成为动态机制
- 新增重点客户、进入新行业、采用新云平台、开展跨境业务时，均应重新评估相关方要求。
- 建立与法务、销售、采购、HR、IT和安全团队的接口，保证变化信息能进入体系。
- 至少在管理评审和年度风险复盘中检查相关方清单是否过时。
成功：有效的4.2会让组织很清楚地知道，哪些要求是“不能谈判的底线”，哪些是“可以通过风险接受或合同澄清处理的边界”。
四、常用工具与实施方法
| 工具/方法 | 应用目的 | 实施建议 | 输出成果 |
|---|---|---|---|
| 相关方矩阵 | 识别相关方及影响程度 | 从影响ISMS和受ISMS影响两个维度打分 | 相关方优先级清单 |
| 要求台账 | 集中管理各类要求 | 按来源、强制性、控制责任、验证证据分类 | 信息安全要求总表 |
| 合同条款审查模板 | 识别客户和供应商安全要求 | 重点审查通知时限、审计权、日志、删除、分包等条款 | 合同安全差距清单 |
| 法规符合性清单 | 识别监管和合规要求 | 法务与安全共同维护，设更新机制 | 合规义务矩阵 |
| 相关方访谈 | 识别隐含期望 | 对销售、客户成功、采购、HR、法务开展结构化访谈 | 访谈纪要和改进建议 |
扩展：对于以B2B客户为主的企业，建议单独建立“客户安全要求库”，因为客户要求通常是ISO 27001落地中变化最快、最直接的外部驱动因素。
五、典型案例
案例一：云服务企业从“客户导向”升级为“客户要求治理”
- 背景：企业客户数量多，安全问卷和合同附件要求差异很大。
- 问题：销售和交付团队分别应对客户要求，未纳入统一体系，导致承诺不一致。
- 4.2动作：建立客户安全要求库，统一归类日志、审计权、分包、漏洞修复和事件通知要求，并映射到流程与控制项。
- 结果：客户要求响应效率提升，超额承诺和遗漏承诺明显减少。
- 启示：客户多并不代表只能被动响应，4.2完全可以把离散要求收敛成制度化能力。
案例二：跨境电商重新识别数据主体和监管方要求
- 背景：企业在多个市场运营，处理用户注册、支付和物流信息。
- 问题：过去只把平台客户和支付机构视为相关方，忽视数据主体、当地监管和仓配合作方。
- 4.2动作：补充识别数据主体、境外监管机构和第三方物流，对个人信息保护、事件通知、删除与访问请求建立承接流程。
- 结果：体系覆盖面更完整，跨境合规风险明显下降。
- 启示：谁受你的安全管理影响，谁就可能是你的相关方。
案例三：制造业供应链安全要求进入ISMS
- 背景：企业核心客户要求对供应商实施安全审查，并对远程运维进行管控。
- 问题：采购合同和安全制度脱节，供应商账号管理粗放。
- 4.2动作：将客户的供应链要求转化为内部供应商准入、保密条款、访问审批和退出回收要求。
- 结果：客户审计通过率提高，第三方接入风险下降。
- 启示：相关方要求往往会“穿透”到组织内部流程和第三方管理。
六、成文信息管理要求
4.2同样没有规定唯一文件名称，但审核时通常要求看到组织已识别相关方、理解关键要求并确定其在ISMS中的承接方式。成熟组织一般会把这部分内容做成可维护的台账，而不是散落在合同、邮件和个人理解中。
| 建议文件或记录 | 关键内容 | 责任角色 | 审核价值 |
|---|---|---|---|
| 相关方识别表 | 相关方类别、影响程度、接口部门 | 体系负责人 | 证明识别范围充分 |
| 信息安全要求台账 | 要求来源、强制性、适用范围、承接条款、验证方式 | 法务/合规/安全 | 证明要求已转化管理 |
| 合同和法规审查记录 | 关键条款摘要、差距、决策和责任人 | 法务/销售/采购 | 证明要求不是停留在概念层面 |
| 更新记录 | 新增客户、法规更新、业务变化引发的修订痕迹 | 体系办 | 证明4.2具备动态维护能力 |
警告：如果4.2只保留一张“客户、员工、监管机构”的清单，但无法证明关键要求如何落到制度、流程和合同中，审核时通常会被认定为理解不充分。
七、常见误区及踩坑提醒
| 误区 | 典型表现 | 正确做法 |
|---|---|---|
| 把相关方等同于客户 | 忽略监管、供应商、员工和数据主体 | 从影响和被影响两个角度全面识别 |
| 只识别显性合同条款 | 忽略审计问卷、行业惯例和隐私期望 | 识别显性与隐性要求并分类处理 |
| 全部要求一律纳入 | 体系过度承诺、执行压力失控 | 根据相关性、强制性和风险影响做筛选 |
| 要求识别后没有承接路径 | 没有对应流程、控制点和责任人 | 在台账中明确承接条款和验证方式 |
| 更新依赖个人经验 | 客户和法规变化后无人同步体系 | 建立跨部门接口和触发更新机制 |
警告：避免只识别客户、忽视隐性要求或没有转化路径，确保第4.2条得到有效实施，使信息安全管理体系真正回应合规、合同与运营要求。
小结：第4.2条解决的是“对谁负责、满足什么要求、哪些要求要进入体系”这一核心问题。只有把关键相关方及其需求和期望识别清楚，并转化到制度、流程和控制中，信息安全管理体系才不会脱离实际。