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

二、条款解读说明

6.3.1 是 6.3 的核心部分，因为它直接处理内部治理结构。第6章后续会出现大量控制要求，但这些控制并不会自动找到负责人和接口。内部组织条款存在的意义，就是在正式控制指南层面说明: 组织必须为这些控制准备好角色、职责、分离机制、对外联系和项目嵌入方式。也就是说，6.3.1 不是单独的“组织设计话题”，而是所有控制能否真正执行的前提。

在 PIMS 里，内部组织的难点通常比普通 ISMS 更高。原因是 PII 处理天然跨越法务、业务、产品、技术、采购、客服、人力、供应链和管理层，多数控制都不是单一团队能独自完成的。一个主体请求流程可能同时涉及身份核验、法律判断、系统检索和答复留证；一项供应商控制同时涉及采购、合同、技术接口和运营监督；一项项目评审可能同时涉及处理目的、角色边界、日志、加密和测试数据。若内部组织仍按传统单线条方式理解，组织很快就会陷入多部门接口失灵的问题。

2019 版在 6.3.1.1 上的补充其实为整个 6.3.1 定下了基调: 内部组织必须围绕 PII 处理建立联络点和治理责任人。这说明本条不是“通用组织学”，而是特定于隐私治理的组织安排。对于控制者，PII 主体联络点和客户联络点尤其关键；对于处理者，客户隐私接口和分包协调接口同样重要。若这些接口没有在内部组织层面被设计，很多后续第7章和第8章义务都会在执行中失去抓手。

职责分离在 PIMS 中也必须重新理解。它不只涉及传统的技术权限分离，也涉及处理目的决定、风险接受、响应关闭、日志查看、供应商审核和例外审批等关键治理动作。内部组织若不考虑这些地方的职责冲突，组织就会频繁遇到“同一个人既提出需求、又批准例外、还负责复核结果”的情况，风险会被显著放大。

从实务看，6.3.1 最容易被低估的是项目嵌入。很多组织在稳定运行期能勉强维持控制，但一到新项目、新系统、新业务合作和重大变更，就会因为没有把隐私要求嵌入项目治理而反复漏项。标准把项目管理中的信息安全放在内部组织下，恰恰是要强调: 项目不是技术过程问题，而是组织内部治理问题。是否有角色、流程和门槛把隐私带进项目，决定了组织能否把风险前移。

因此，6.3.1写作时不能只罗列五个子条款，而要让读者看清一条主线: 组织必须先在内部把角色、分离、联系和项目接口设计清楚，后面的控制才可能稳定成立。只要这个内部组织框架存在，第6章后续的大量条款都会更容易落地。

三、实施要点

• 围绕 PII 处理高频场景梳理角色、接口和升级关系，而不是只从静态岗位名称出发设计组织。
• 对高风险治理动作明确职责分离要求，避免决定、执行和复核长期落在同一人手里。
• 建立与监管、客户、合作方和专业机构的正式联系路径，不要临时找人顶上。
• 把项目和重大变更纳入内部组织设计，让隐私评审前移到业务启动阶段。
• 6.3.1的核心是为 PIMS 建立可运作的内部治理框架，而不是只做岗位分配。

四、常用工具与实施方法

一个非常有效的做法，是不要先画大而全的组织图，而是先挑几个最容易暴露治理问题的场景做演练，例如“收到复杂删除请求”“新增高风险供应商”“新项目要上线敏感功能”。通过这些场景倒推，组织通常更容易发现真正缺失的角色和接口。

对小组织而言，也不意味着必须设置大量专职岗位。更现实的做法，是通过明确兼职职责、升级路径和复核机制，把有限资源组织起来。6.3.1 的重点不在岗位数量，而在治理关系是否清晰。

五、典型案例

1. 岗位很多但协作关系空白：某企业文件里列了隐私负责人、法务、安全经理和客服主管，但在实际请求和项目审批中，这些角色之间没有清晰接口，导致事项一到复杂场景就需要临时拉群协调。问题根源不是没人，而是 6.3.1 没有把内部组织真正设计出来。
2. 项目从不提前引入隐私角色：另一家组织每次新项目都在接近上线时才让隐私团队介入，导致大量返工。后来将项目控制门和角色嵌入放入 6.3.1 设计后，评审才开始真正前移。

这些案例说明，内部组织最重要的不是“岗位齐全”，而是“接口能工作”。接口一旦清楚，治理成本往往比组织想象中更低，因为大量问题不再需要反复解释和重新协调。

六、成文信息管理要求

这些文件可以帮助组织证明，内部组织不是停留在描述层，而是已经细化到可执行场景。对后续审核和培训来说，这类证据非常有价值。

七、常见误区及踩坑提醒

内部组织真正稳固的标志，不是图上岗位分得很细，而是各岗位之间的交接关系足够清楚。新系统上线、例外批准、客户投诉和安全事件如果都需要多个团队配合，就必须事先约定谁提出、谁判断、谁批准、谁保留证据。只有把这些接口固定下来，内部组织才不是静态岗位说明，而是能够持续支撑 PII 管理的运转结构。