一、ISO/IEC 27701:2019 7.3.8 标准原文
原文摘要：标准要求当 PII 主体提出请求时，组织应能够提供其处理的 PII 副本。实施指南指出，副本应以主体可访问的结构化、常用格式呈现，并仅与该主体相关；如果相关 PII 已根据保留和处置政策删除，应告知主体；如果组织因去识别化等原因无法识别主体，不应仅为此重新识别，但在适用法域下可以请求必要补充信息；在技术上可行时，也可根据请求直接将副本传输至另一组织。
二、条款解读说明
7.3.8 看似只是“把数据给主体”，实际上是主体权利体系里技术和治理耦合度最高的条款之一。因为副本请求不是单纯证明组织持有哪些信息，更涉及信息整理、字段解释、身份核验、范围控制、格式选择和安全传输。组织若只从技术角度理解为导出数据库记录，往往会把大量上下文信息、日志字段、关联对象和第三方数据一起打包出去，结果反而引发新的泄露风险。
标准强调副本应采用结构化、常用且主体可访问的格式，这一点很关键。主体要副本，通常不是为了看一堆难懂的内部字段名，而是为了理解组织究竟处理了哪些 PII、如何进一步使用这些信息，以及在必要时将信息转移到另一服务。结构化和常用格式意味着组织应考虑机器可读性和后续复用场景；可访问意味着输出方式不能只照顾技术团队，而应照顾主体的理解和接收能力。
| 核心问题 | 7.3.8要求 | 容易出错的点 |
|---|---|---|
| 范围界定 | 只提供与该主体相关的PII副本 | 导出中混入他人信息或内部备注 |
| 格式选择 | 结构化、常用、主体可访问 | 只给技术内部格式或图片截图 |
| 身份核验 | 确认请求人确为相关主体或合法代理 | 核验不足导致错发 |
| 删除说明 | 若数据已依法删除，应明确告知 | 主体以为组织拒绝配合 |
| 直接转移 | 技术可行时可直接传输到另一组织 | 未评估安全传输条件 |
本条还有一个常被忽略的边界：如果组织已经无法识别主体，例如数据已经做了充分去识别化，标准并不要求组织仅为了满足副本请求而重新识别全部数据。但这并不意味着组织可以轻易以“无法识别”为由拒绝所有请求。更稳妥的做法，是说明当前可识别程度、必要时请求主体补充合理信息，并记录为何可以或不可以继续匹配相关记录。
在跨平台和平台迁移场景下，7.3.8 也与可携带性直接相关。主体之所以需要副本，往往不只是出于好奇，而是希望了解自己的数据被如何使用，或者在更换服务商时减少重复录入成本。组织若能把副本提供机制建设得清楚、准确、安全，就能显著降低主体与组织之间的信息不对称。
因此，7.3.8 的本质不是“导一份数据”，而是建立一套兼顾主体可用性、数据边界和安全传输的副本交付能力。这项能力越成熟，组织越能从容应对高频访问请求、迁移诉求和合规抽查。
从审查实践看，7.3.8 真正考验的是组织能否在“找全数据”和“不给错数据”之间保持平衡。主体请求副本时，系统里可能同时存在原始字段、推断结果、日志信息、注释、关联对象和第三方来源信息。控制者如果只是简单导出后台表单，很容易把不属于该主体的数据、内部运维字段或难以理解的技术代码一起交出去；但如果过度保守，又可能遗漏本应提供的重要信息。
这条控制还涉及可用性问题。标准强调结构化、常用格式，意味着组织输出的副本不应只是技术可打开，更应让主体知道每个字段代表什么、时间范围是什么、哪些数据已因保留策略删除、哪些信息来自推断或外部来源。没有这些辅助说明，副本即使形式上给到了，主体也未必能真正理解和使用，更谈不上在必要时转移给其他组织。
三、实施要点
- 明确哪些字段属于主体可请求的 PII 副本范围，哪些内容因涉及他人或内部安全信息需要排除或处理。
- 统一副本输出格式，优先选择结构化、常用且便于解释的交付方式。
- 在导出前完成身份核验和内容复核，避免错发、漏发和混发。
- 对已删除、已去识别化或技术上无法直接提供的部分，形成清楚解释口径和证据。
- 7.3.8的核心是把副本请求做成安全、准确、可理解的受控交付，而不是一次性技术导出动作。
四、常用工具与实施方法
| 工具/方法 | 适用目的 | 关键输出 |
|---|---|---|
| 副本字段清单 | 界定可提供范围与排除范围 | 字段目录、解释说明、敏感标记 |
| 导出模板与格式标准 | 统一结构化输出方式 | CSV、JSON、PDF摘要或组合交付模板 |
| 身份核验与复核流程 | 降低错发和混发风险 | 核验记录、二次复核结果 |
| 安全传输方案 | 支持加密下载或直接转移到其他组织 | 下载链接、传输日志、接收确认 |
实践中，最稳妥的做法通常不是只给一份原始数据文件，而是同时提供简要字段说明、时间范围说明和格式说明。这样主体能够读懂，组织也能减少“为什么这里看不见某字段”的反复沟通。
对于多系统环境，组织还应考虑副本中的时间切片问题。某些系统是实时数据，某些是延迟同步，若不说明导出时点和数据来源，主体看到的副本就可能与前台页面显示存在短期差异，引发不必要争议。
在实施方法上，组织最好把副本交付设计为一条受控导出流程，包含身份核验、数据检索、范围过滤、第三方信息剔除、字段说明和安全交付方式选择。对大型系统来说，还应建立统一的“主体主数据定位逻辑”，否则同一主体在不同业务线的记录无法准确聚合，副本质量就会高度不稳定。
五、典型案例
- 导出过度：某平台响应副本请求时，直接导出内部后台表，结果连人工审核备注、风险标签和其他用户关联标识也一起输出，引发新的保密和申诉问题。
- 格式不可用：另一家企业虽然提供了副本，但内容是一组难懂的系统代码和字段缩写，主体无法识别哪些是基本资料、哪些是交易记录、哪些是推断标签，副本权因此失去实际价值。
这些案例说明，7.3.8 真正追求的是“既给得到，又给得对，还给得能用”。如果只满足其中一项，副本交付仍然是不成熟的。
六、成文信息管理要求
| 建议保留文件 | 关键内容 |
|---|---|
| 副本交付规则 | 范围界定、格式要求、核验方式和排除逻辑 |
| 请求与交付记录 | 请求时间、受理人、交付内容、交付方式和完成时间 |
| 复核与例外记录 | 为什么某些数据被排除、为何无法识别或已删除 |
| 安全传输日志 | 下载、加密、直接转移和接收确认信息 |
这些记录能帮助组织证明，副本提供不是随意导出，而是经过边界判断、身份核验和交付控制的正式过程。
成文信息管理上，7.3.8 应保留请求范围、身份核验结果、导出时间、导出所依据的系统版本、字段说明、传输方式和拒绝或删减理由。因为提供副本本身也是高风险动作，组织既要能证明向正确主体交付了正确数据，也要能说明为何某些信息未提供或已被合法删除。
七、常见误区及踩坑提醒
| 误区 | 问题表现 | 正确做法 |
|---|---|---|
| 导得越多越显得配合 | 混入他人数据或内部敏感信息 | 严格界定副本范围并二次复核 |
| 给了文件就算完成 | 主体拿到后根本读不懂 | 选择常用格式并附字段解释 |
| 无法识别就直接拒绝 | 未说明去识别化或补充核验逻辑 | 如实解释边界并记录判断依据 |
本条最容易失效的原因，是组织把副本请求看成简单导出任务，没有对身份、范围、格式和第三方信息进行二次校验。这样做的结果往往是两头失守，要么交付内容过少引发争议，要么因为导出过量或误含他人数据而制造新的泄露事件。