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

二、条款解读说明

6.9 是第六章里非常核心的一组控制，因为它覆盖了系统真正产生持续风险的阶段: 日常运行。很多组织在建设阶段会集中投入大量精力制定策略、做架构设计、划清角色和部署技术工具，但一旦系统稳定上线，控制就容易滑向“按惯例运转”。正是在这个阶段，PII 风险最容易被日常化。备份是不是按真实需求做的，日志是不是能看清谁访问过什么数据，变更是不是评估过隐私影响，测试环境是不是偷偷混入真实资料，安装软件和打补丁是不是留下了旁路，这些都属于运行安全的范畴。

从结构上看，6.9.1 关注操作规程、变更、容量和环境分离，解决的是“系统怎么被稳定地、安全地运转”；6.9.2 关注恶意软件，解决的是“系统怎样避免被常见攻击面拖垮”；6.9.3 关注备份和恢复，解决的是“PII 在丢失、损坏、攻击和灾害后如何可恢复且恢复得正确”；6.9.4 关注日志和监视，解决的是“运行中的 PII 接触行为能否被记录、保护和复盘”；6.9.5 到 6.9.7 则进一步覆盖运行软件安装、技术脆弱性和审计活动对运行系统的影响。

2019 版对 6.9 的补充很能说明 PIMS 与一般信息安全的差别。以备份为例，标准不是简单要求“做备份”，而是要求组织考虑 PII 的备份、恢复和删除要求，说明客户可能承担的责任，并向客户清楚说明备份服务的能力和限制。也就是说，对 PII 来说，备份不是后台技术动作，而是合同、法域要求、恢复质量和客户透明度共同作用的控制。

日志同样如此。标准在可能情况下要求记录谁在何时访问了哪个 PII 主体的 PII，以及做了哪些更改；若日志本身含有 PII，则还必须受控访问并按计划删除或去标识化；若客户可访问日志，则必须隔离不同客户的可见范围。这意味着日志既是调查证据，也是潜在的 PII 载体，本身也需要被治理。

从运行实践看，6.9 最难的不是不知道应该做什么，而是容易在长期运转中失去纪律。上线初期所有规程都有人盯，半年之后临时变更多了、补丁窗口紧了、备份失败靠人工补做、日志容量不够就先覆盖、测试环境偶尔导一份真实数据方便排查，问题就开始出现。PIMS 的价值之一，就是通过 6.9 把这些“方便一下”的动作重新纳入正式边界。

因此，6.9 的本质是让 PII 处理系统在每天运行的过程中保持一致、可预测和可审计。系统不是只在架构图和上线验收里安全，而是要在日复一日的备份、监控、修补、变更、恢复和排障过程中持续安全。

三、实施要点

• 将运行安全视为“PII 日常处理纪律”，而不是单纯的 IT 运维章节。
• 把规程、变更、备份、日志和脆弱性管理联成一套闭环，不让关键动作碎片化。
• 对客户责任、法域要求和多方交付模式做额外设计，特别是在备份与日志场景中。
• 把恢复、排障、应急变更和审计活动纳入隐私边界，而不是只覆盖正常状态。
• 6.9的核心是让系统在持续运行时，仍能稳定地按既定规则处理、恢复和记录 PII。

四、常用工具与实施方法

实践中，组织不应把运行安全仅交给技术团队单向执行。因为备份保留多久、日志让谁看、恢复后如何确认 PII 完整性、测试环境能否接触真实数据，这些问题都涉及业务、法务、客户管理和隐私治理团队的共同判断。只有多方参与，运行控制才不至于偏成“技术上能做就做”。

对于提供处理服务的组织，还应把 6.9 的若干控制转化成客户可理解的说明，例如备份能力边界、恢复承诺、日志可用性和客户访问日志的条件。否则内部做了很多控制，外部仍然无法判断服务是否满足 PII 处理责任。

五、典型案例

1. 备份做了，但恢复逻辑没对齐：某处理者能够恢复数据库，却没有恢复后校验 PII 是否完整和是否与客户当前状态一致，结果恢复出来的是陈旧记录和缺失字段，导致后续处理判断失真。问题不在有没有备份，而在 6.9 的运行链条没有闭环。
2. 日志很多，却回答不了隐私问题：某平台记录了海量系统日志，但无法说明是谁在何时查看过某个主体的信息，也没有隔离客户可见的日志范围，导致事件发生后既查不清内部访问，也不敢给客户开放查看权限。

这些案例说明，运行安全真正要交付的不是“系统很忙很复杂”，而是“组织能持续说清楚 PII 在运行中是怎么被处理、被恢复和被记录的”。

六、成文信息管理要求

这些资料能证明组织不是一次性搭建了一套控制，而是在运行过程中持续维持了与 PII 相关的纪律、证据和可追溯性。

七、常见误区及踩坑提醒