一、ISO/IEC 27701:2019 6.9.3 标准原文
原文摘要：本条对应 ISO/IEC 27002:2013 12.3，包括 6.9.3.1 信息备份。2019版在一般备份要求基础上补充提出：组织应制定满足 PII 备份、恢复和恢复要求的策略，并考虑从备份信息中删除 PII 的进一步要求；PII 的具体责任可能取决于客户，组织应向客户说明备份服务限制；若明确向客户提供备份和还原服务，应向其提供有关备份与恢复 PII 能力的明确信息；组织在相关法域运营时应证明满足特定备份、测试和恢复要求；恢复 PII 时需建立确保完整性或识别不准确、不完整状态并解决的流程；恢复工作应形成日志，至少记录负责恢复的人员姓名和恢复的 PII 说明。整体上，6.9.3要求组织把备份从单纯存一份副本，提升为围绕 PII 的可信恢复能力。
二、条款解读说明
6.9.3 是 27701 在运行安全中最具隐私特征的条款之一。与一般信息安全中的备份不同，这里关注的并不只是数据能否在故障后恢复，更关注恢复回来的 PII 是否完整、准确、符合法律和合同要求，以及组织是否清楚说明了与客户之间的责任分工。也就是说，备份在 PIMS 中不是后台技术动作，而是恢复责任、客户透明度、法域要求和主体权益共同交叉的控制点。
标准首先要求组织建立关于 PII 备份、恢复和删除的策略。这一点很重要，因为很多组织虽然有统一备份策略，但并未单独考虑 PII 的特殊要求。例如，哪些含 PII 的数据必须加密备份，哪些备份副本受删除或更正请求影响，哪些历史副本在合同到期后仍可保留，哪些恢复动作需要与客户确认。若没有把这些问题写进策略，备份就会变成“技术上做到了，治理上解释不清”的灰区。
| 备份控制维度 | 一般安全关注点 | PIMS额外关注点 |
|---|---|---|
| 备份范围 | 是否包含必要系统和数据 | 是否包括与 PII 处理相关的日志、配置和删除要求 |
| 恢复能力 | 能否在时间目标内恢复 | 恢复出的 PII 是否完整、准确且可解释 |
| 责任划分 | 谁执行备份和恢复 | 客户与处理者之间谁负责哪些备份义务 |
| 保留与删除 | 副本保存多久 | 备份中的 PII 是否受法律、合同和主体请求影响 |
2019 版还特别强调客户责任和服务限制。对处理者场景来说，组织不能默认客户明白“我们有备份”具体意味着什么。客户需要知道备份频率、恢复边界、是否提供按主体级别恢复、是否支持删除后的备份清理、以及哪些能力因架构或合同限制而无法提供。否则一旦发生故障、删除请求或争议，双方会对责任边界产生完全不同的理解。
标准进一步要求恢复 PII 时建立确保完整性或识别不准确和不完整状态的流程，并记录恢复日志。这表明备份真正的终点不是把系统拉起来，而是恢复出可继续用于处理且状态清楚的数据。若恢复后数据不完整、时间点不清、与客户当前状态不一致、或无法说明是由谁在何时恢复的，组织就很难证明恢复结果是可信的。
因此，6.9.3 的本质是围绕 PII 建立“可恢复且可解释”的备份能力。副本存在只是起点，恢复质量、责任边界、删除要求和恢复证据才决定这条控制是否真正成立。
三、实施要点
- 在统一备份策略中单独识别 PII 备份、恢复和删除要求，不把它们隐藏在一般性描述里。
- 明确客户、控制者和处理者在备份、还原、保留和限制说明上的责任边界。
- 将恢复后的完整性和准确性验证纳入标准流程，而不是把“恢复成功”停留在技术层。
- 为恢复活动保留结构化日志，能够说明谁恢复了什么、在什么条件下恢复。
- 6.9.3的核心是让备份真正支撑 PII 的可信恢复，而不是只留下无法解释的历史副本。
四、常用工具与实施方法
| 工具/方法 | 适用目的 | 关键输出 |
|---|---|---|
| PII备份策略 | 明确备份、恢复、保留和删除要求 | 正式策略文件 |
| 恢复验证清单 | 检查恢复后完整性和准确性 | 恢复验收记录 |
| 客户说明材料 | 说明备份能力和服务限制 | 合同附件或服务说明 |
| 恢复日志模板 | 固定记录关键恢复证据 | 恢复作业日志 |
实践中，组织应把“删除与备份”之间的关系讲清楚。许多系统无法立刻从历史副本中逐条删除某个主体信息，但这并不意味着可以忽略这个问题。更合理的做法，是明确备份副本的适用边界、恢复后如何重新执行删除、以及在合同和隐私说明中如何透明表达。
对跨法域运营或受行业监管的组织，还应把备份频率、保留期、演练频率和恢复日志内容与适用要求对应起来，而不是默认一套全球统一备份策略天然适用所有场景。
五、典型案例
- 恢复成功但数据不可信：某平台从备份恢复后虽然重新提供服务，但恢复点早于一批关键更正操作，导致部分主体资料回到旧状态。团队只确认了系统能用，没有核查恢复后的 PII 完整性和时点解释能力。
- 客户以为有“随时按主体恢复”能力：某处理者在合同中笼统写明“提供备份服务”，客户后来要求仅恢复单个主体的历史记录时才发现系统并不支持这种粒度，双方因此产生争议。根源是备份服务限制未被清楚说明。
这些案例说明，备份的难点从来不只是有没有副本，而是恢复出的 PII 是否正确、责任是否明确以及服务边界是否透明。
六、成文信息管理要求
| 建议保留文件 | 关键内容 |
|---|---|
| PII备份与恢复策略 | 范围、频率、保留、删除和责任划分 |
| 恢复日志 | 恢复人员、恢复对象、时间点和结果 |
| 恢复验证记录 | 完整性、准确性、异常说明和补救措施 |
| 客户能力说明 | 备份边界、服务限制和合规说明 |
这些文件能够证明组织不是简单把数据复制出去，而是围绕 PII 建立了有责任边界和证据链的恢复能力。
七、常见误区及踩坑提醒
| 误区 | 问题表现 | 正确做法 |
|---|---|---|
| 有备份就等于能恢复 | 恢复质量、恢复点和数据状态不明 | 把完整性和准确性验证纳入流程 |
| 客户默认理解备份能力 | 服务边界和责任分工产生争议 | 明确说明能力与限制 |
| 备份副本与删除请求无关 | 历史副本长期成为治理盲区 | 在策略中写清适用规则和补救方式 |
备份不能只被看成恢复手段，它本身也是另一套承载 PII 的数据资产。很多组织主系统权限清晰，到了备份链路却变成运维专属空间，谁能访问、谁能导出、保存多久、跨什么区域存放都说不清。真正成熟的备份治理，应把副本位置、访问边界、加密状态、恢复授权和清理期限连成同一套规则，确保“为了可用性保存的数据”不会反过来成为机密性短板。
对 PII 而言，备份控制还必须处理一个现实矛盾: 为了抗勒索、抗误删和抗篡改，组织通常会要求备份具有不可变性或隔离性；但为了满足删除、更正、合同到期和保留限制，又不能让历史副本永远脱离治理。成熟做法不是简单选边站，而是提前定义恢复时如何重新执行删除、哪些副本在到期后应整体淘汰、哪些法域不允许长期保留某类历史镜像、以及客户在这方面能得到什么说明。只有把这些冲突写入策略，备份才不会一边增强可用性，一边悄悄侵蚀 PII 生命周期控制。
此外，真正能证明 6.9.3 有效的，往往不是“昨晚备份成功”的报告，而是恢复演练中的细节证据。组织是否测试过把某个主体相关数据从备份恢复后再核验准确性，是否验证过恢复环境本身不会把 PII 暴露给无关人员，是否在演练中记录了恢复人、审批依据、恢复范围、后续清理和异常项，往往比备份成功率更能说明成熟度。对 PIMS 来说，备份的终点不是生成副本，而是在需要时把可继续处理、可继续解释、且不会制造新暴露的数据带回来。