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

二、条款解读说明

5.6.1是运行章节的起点，它解决的是过程层面的问题。也就是说，组织已经识别了风险、确定了控制、配置了支持条件，接下来必须回答：这些要求在真实运行中具体由哪些过程承接，按什么标准承接，由谁承接，留下什么证据。很多体系失败并不是因为前面没有做规划，而是因为这些规划没有进入日常流程，最终只能靠个别人记忆和额外提醒来维持。5.6.1正是为了解决这种“规划和执行之间的断层”。

在 PIMS 语境下，过程控制对象远不止传统的信息安全运行活动。它还包括处理活动设计、主体请求受理、分包评审、合同流转、日志和监视安排、保留删除执行、内部升级、对外通知以及各类变更活动。也就是说，凡是会影响 PII 处理结果的过程，都应被纳入运行规划和控制。组织若仍按纯 ISMS 视角理解这一条，只围绕系统运维、备份和权限管理来设计过程，PIMS 运行就会天然缺一半。

标准要求为这些过程建立准则，并按照准则实施控制。所谓准则，并不是一堆抽象原则，而是能够被执行的具体判断标准。例如，什么变更需要重新做风险评估，什么情况下请求必须升级法务，什么类型的数据导出必须审批，什么供应商在何种条件下必须重新审查，什么证据属于关闭请求的最低要求。这些准则越清楚，过程越不依赖个人经验；准则越模糊，组织越容易出现“大家都觉得自己在按要求做，但做出来完全不一样”的情况。

文件记录信息在 5.6.1 中的作用也非常现实。标准不是要求每个动作都留下海量材料，而是要求保留足够证据，证明过程确实按策划执行。对 PIMS 来说，最有价值的往往是“关键节点证据”，例如审批记录、评审纪要、系统截图、工单状态、变更单、通知记录和验收结论。只要这些关键节点没有证据，组织很难说明过程控制是否真实存在。

这一条在运行中还天然包含对变更和外部提供活动的关注。因为过程最容易在变化中走样，而外部提供的服务、系统或人员又常常不在组织直接管理之下。若组织只把 5.6.1 做成内部静态 SOP，就无法覆盖真实业务中的大量例外和外部接口。成熟的做法，是让过程控制既能管住常规流程，也能吸收变更和第三方场景。

因此，5.6.1的关键不是“有流程图”，而是“流程里真的有隐私控制门，流程外发生变化时也有补救机制”。只有这样，PIMS 才能在日常运行中具备一致性和可追溯性。

三、实施要点

• 识别真正影响 PII 处理结果的关键过程，而不是只盯住传统技术运维流程。
• 为每个关键过程设置清晰准则，包括触发条件、责任人、审批路径、时限和最低证据要求。
• 把5.4确定的风险处置措施嵌入过程节点，让控制在流程里自然发生。
• 同时关注常规运行、变更场景和外部提供活动，避免过程控制只覆盖“平稳状态”。
• 5.6.1的核心是让隐私治理成为过程属性，而不是临时插入动作。

四、常用工具与实施方法

如果组织担心流程过重，可以优先对高风险过程设置更细控制，对低风险过程采用较轻机制。这样既能保持效率，也能让最关键的隐私活动获得足够保护。关键在于风险和过程强度相匹配，而不是一刀切。

对于多部门参与的流程，建议明确“谁是流程拥有者”，否则过程控制很容易在接口处失效。PIMS 里的很多问题都不是单部门能独自完成的，流程拥有者越清晰，运行稳定性越高。

五、典型案例

1. 需求评审里没有隐私控制门：某产品团队每次新增字段都只经过业务和研发评审，从不检查是否扩大处理范围。早期问题不明显，业务复杂后才集中暴露。组织依据 5.6.1 在需求评审中加入隐私检查点后，风险识别明显前移。
2. 请求流程靠个人记忆维持：某企业主体请求处理一直由几位资深客服凭经验完成，结果人员轮换后请求质量迅速下降。复盘发现，组织从未把核验、升级和关闭准则写进正式过程。补做 5.6.1 后，流程才不再依赖关键人。

这些案例说明，真正的过程控制价值在于降低对个人经验的依赖，让同类事情无论谁来做、在哪个团队做，都能得到相近质量的结果。

六、成文信息管理要求

这些材料可以帮助组织回答一个关键问题：过程是不是真的在按设计运行。尤其在审核和内部复盘时，流程设计本身远不如流程执行证据更有说服力。

七、常见误区及踩坑提醒