一、ISO/IEC 27701:2019 5.3.3 标准原文

二、条款解读说明

5.3.3是 2019 版中一个典型的“条文短、实施重”的条款。它沿用了 ISO/IEC 27001:2013 第5.3关于职责和权限分配的要求，但由于 5.1 已将“信息安全”扩展为“信息安全和隐私”，原有职责分配逻辑就必须同步扩展。也就是说，组织不能只保留原来的信息安全负责人、审核负责人和过程负责人，而要进一步明确：谁负责角色识别、谁负责主体请求流程、谁负责分包管理、谁负责返还或处置、谁负责隐私风险评估、谁负责将体系绩效向管理层汇报。

这一条最关键的点，是“职责”和“权限”必须同时存在。很多组织在文件中会写“隐私负责人负责监督PIMS”，但当该负责人需要推动整改、调取数据流信息、要求业务解释处理目的或阻止高风险分包时，却没有足够权限。这样的职责分配在 27701 语境下并不成熟。因为 PIMS 涉及法务、产品、业务、IT、采购、客服、人力等多种岗位，只有职责和权限同时匹配，体系才可能真正运行起来。

在27701语境下，职责分配还必须考虑角色差异。同一个岗位，在控制者场景和处理者场景下承担的责任往往并不一样。例如合同负责人在控制者场景下更关注告知、合法基础和第三方共享条款，在处理者场景下则更关注客户指令、分包限制、返还和通知义务。产品和运营负责人在控制者场景下更直接面对主体影响，在处理者场景下则要更加谨慎地避免超越客户授权。5.3.3如果不把这些差异纳入职责设计，组织就会出现“岗位名称一样，实际义务完全不同，却没有人明确区分”的问题。

从审核实践看，5.3.3常常不是看制度写得多细，而是看访谈时岗位是否真的知道自己要做什么。比如客服是否知道什么时候触发主体请求流程，采购是否知道什么时候分包安排必须升级评审，开发负责人是否知道什么时候要做隐私风险评估，业务负责人是否知道在哪些场景下需要重新判断自己是控制者还是处理者。如果岗位本人说不清，哪怕文件写得很完整，审核员通常也会认为职责并没有真正被沟通和内化。

因此，5.3.3的核心不是“再设一个岗位”，而是把职责网络做实。很多时候，并不需要新增太多专职岗位，而是需要让现有岗位在各自流程里显性承担隐私责任，并为这些责任提供清晰权限和升级路径。只要职责与权限对齐，PIMS 的执行成本通常会显著降低，因为组织不再需要每次遇到问题都临时找人协调。

这一条还有一个非常现实的价值，就是帮助组织把“隐私工作依赖个人经验”的状态转变为“隐私工作依赖职责设计”的状态。只要职责能被结构化表达，人员变动、组织调整或项目切换时，体系的稳定性通常会明显提高。这也是为什么 5.3.3 虽然沿用了 27001 条款，但在 PIMS 里仍然必须被认真重写解释。

三、实施要点

• 在现有职责矩阵中显性加入 PIMS 责任，不要默认原有ISMS职责会自动覆盖隐私问题。
• 围绕体系符合性、运行执行、绩效报告和问题升级四类责任建立清晰分工。
• 同步审查关键岗位权限，确保其有能力调取信息、发起整改和参与决策。
• 对控制者场景和处理者场景下同名岗位的职责差异做出明确说明。
• 5.3.3的重点是职责和权限成对出现，否则责任很容易变成纸面责任。

四、常用工具与实施方法

很多组织真正把 5.3.3 做起来，靠的不是再画一版组织架构图，而是把职责拆到可操作场景中。例如“收到删除请求时谁牵头”“更换分包方时谁发起评审”“新增营销用途时谁重新判断合法性基础”。只要职责能落到场景，岗位通常就更容易记住和执行。

五、典型案例

1. 有职责表但没人真负责：某企业文件中列了十几个与隐私有关的岗位，但一线访谈时无人能说明自己在主体请求、分包管理和事件升级中的具体责任。后来组织按 5.3.3 重写职责矩阵，并做场景化培训，执行效果明显改善。
2. 只有职责没有权限的失败案例：另一家组织任命了隐私负责人，但该岗位既无权参加项目评审，也无权调取系统配置和合同信息。结果负责人名义上承担职责，实际无法推动改进。依据 5.3.3 调整授权后，体系才逐步稳定。

这些案例说明，职责设计如果只停留在文件里，就会让体系执行始终处于“出了问题再临时协调”的低成熟状态。5.3.3的意义，就是把这种低成熟状态系统性地扭转过来。

从发布视角看，这一条最需要写透的是“职责网络”而不是“岗位名录”。读者真正需要的不是再看一遍谁是谁，而是理解为什么隐私治理一旦缺少明确职责和权限，就会在最关键的请求、事件、分包和整改场景中频繁失控。

六、成文信息管理要求

这些文件的价值，在于把“职责和权限已分配并沟通”这件事变成可验证事实。尤其是对2019版这种文字简洁的条款，组织越需要用证据说明自己不是简单照搬 27001，而是真正做了隐私语境下的扩展。

七、常见误区及踩坑提醒