O2.13.3Living third-party recipient register设计研究
披露清单需要随合作方变化及时更新而非一次性公示
别名: 动态第三方清单 · 接收者变更日志 · third-party register freshness
概念解释
持续更新的第三方接收者登记表（living third-party recipient register）把披露当成与供应商生命周期同步的运行数据，而不是产品上线时写完就不再变的文档。它记录接收者何时加入、移除、改名、改变角色或扩大数据范围，并让用户能区分当前关系与历史关系。
机制
供应商可通过远程配置、SDK 更新、子处理方变更和并购在无前端发布的情况下变化。手工维护的政策页与采购、代码和网络配置分离时，披露必然漂移。将供应商台账作为披露的结构化来源，并由运行时观测反向检查，才能让新鲜度成为可验收属性。
怎么研究
在测试环境中依次注入新供应商、子处理方、域名变更、数据范围扩大与合同终止，测量从业务生效到内部台账、用户清单、变更通知和停止传输的各段延迟。比较清单 diff 与网络、服务端和采购记录，检查新增、删除和范围变更的双向完整性。更新页面的时间戳不能证明所有条目都是新的。
边界
并非每个负载均衡节点、CDN 主机名或公司内部系统都是需单独呈现的数据接收者，应按控制与目的的实质边界聚合。临时故障切换与长期新接收者可使用不同通知强度，但只要发生个人数据传输，就应在合理时间内可追溯。历史条目不应被现状覆盖，否则无法追查过去事件。
怎么落地
- 以统一供应商 ID 连接采购、安全评审、合同角色、域名、SDK、数据类别和用户披露。
- 将新增、子处理方、目的/范围扩大、改名、并购和终止作为结构化事件，为每类定义更新与通知预算。
- 在当前清单中显示最后核验日期，同时保留可按日期查找的历史版本和变更摘要。
- 在发布与持续监测中对账台账和真实传输；未登记域、已终止方仍收到数据或披露超过预算都触发告警。