一、GB/T 35273-2020 9.7 标准原文

二、条款解读说明

2.1 第三方接入是现代产品的高频场景，也是隐蔽风险源

地图、支付、客服、统计、广告、登录、分享、视频播放、风控、推送、小程序和各种SDK、脚本、接口，几乎构成了现代数字产品的基础组件。很多第三方功能本身具备收集个人信息能力，但其处理目的、收集方式和责任主体并不完全等同于平台自身。GB/T 35273-2020第9.7条要求平台建立第三方接入管理机制，对接入条件、合同约束、前台标识、授权同意、投诉机制和持续监督进行系统治理。

2.2 9.7强调平台不能“接完即放手”

2.3 平台虽非唯一责任方，但负有把关义务

9.7适用的场景往往是第三方作为独立提供者，在平台环境中向用户提供功能或服务。虽然第三方需要自行根据标准要求征得授权同意并处理用户请求，但平台并不能因此完全置身事外。标准明确要求平台建立接入管理机制、核验第三方实现同意的方式、监督其个人信息安全管理，并在必要时停止接入。换句话说，平台是接入行为的组织者，也是风险把关者。

2.4 自动化工具接入是最容易失控的技术点

第9.7条特别提出，对于代码、脚本、接口、算法模型、软件开发工具包、小程序等第三方自动化工具，宜开展技术检测和审计。这是因为自动化工具通常嵌入深、更新快、真实行为不完全透明，极易出现超范围采集、隐蔽上传、灰度变更、静默新增字段等问题。若平台仅依赖第三方文档说明，不做技术核验，就很容易产生“说的是一套，实际跑的是另一套”的风险。

2.5 明确标识第三方提供，是降低误导风险的基本要求

标准要求向个人信息主体明确标识产品或服务由第三方提供。这个要求看似简单，实则非常关键。用户只有知道自己正在进入第三方服务，才可能理解为何会跳转到不同页面、看到不同规则、向不同主体提交个人信息。如果平台把第三方服务包装成自有服务，用户的知情和选择都会被削弱。

三、实施要点

3.1 建立第三方接入准入流程

• 对接入需求进行业务必要性、安全能力和权限范围审查。
• 对高风险第三方建立安全评估和灰度验证门槛。
• 无明确责任主体或无隐私治理能力的第三方不应接入。

3.2 做实合同、标识和授权要求

• 合同中明确第三方的收集边界、同意义务、投诉响应和整改责任。
• 在前台清晰标识服务由第三方提供，并展示必要说明。
• 必要时对第三方授权弹窗、隐私说明和关闭路径进行核验。

3.3 建立运行期技术检测与审计

• 定期抓包、日志比对、行为检测，核查第三方实际收集和传输内容。
• 对SDK、脚本、小程序和接口版本变化进行风险复审。
• 发现超范围行为及时断开接入并启动整改。

3.4 保证用户请求和投诉可达

• 要求第三方建立可联系、可处理的权利响应和投诉机制。
• 平台应留存联系路径，并在用户无法直达时提供辅助指引。
• 对高频投诉第三方启动专项复查或停用。

四、常用工具与实施方法

五、典型案例

案例1：App接入广告SDK后出现超范围采集

1. 背景：某应用接入广告SDK，后续版本新增收集设备标识和行为字段，但平台未及时发现。
2. 问题：缺少运行期技术检测和版本审查，接入后失控。
3. 改进：建立SDK版本白名单和定期检测机制，发现超范围即下线。

案例2：第三方服务没有明确标识

1. 背景：用户在平台内使用保险服务，前台页面完全没有提示该功能由第三方提供。
2. 问题：用户无法识别责任主体，也不知道应向谁主张权利。
3. 改进：在入口页、授权页和隐私说明中明确第三方身份和联系路径。

案例3：用户投诉第三方无法联系

1. 背景：用户对接入的小程序提出删除请求，但第三方无公开投诉通道。
2. 问题：平台未在准入阶段核验其请求响应机制。
3. 改进：将投诉和权利响应能力作为接入前提，对不达标第三方停止接入。

六、成文信息管理要求

9.7要求平台能够证明其已对第三方接入实施准入、约束、标识、核验和持续监督，因此接入类资料必须系统化归档。

1. 建议保留的成文信息
   • 第三方接入准入标准、评估结论和审批记录
   • 接入协议、责任分工、整改要求和下线条件
   • 前台标识方案、用户告知材料和第三方联系路径
   • 技术检测、版本审计、抓包分析和异常整改记录
   • 投诉数据、权利响应核验结果和停用下线记录
2. 管理要求
   • 第三方自动化工具更新后应重新进入检测流程。
   • 高风险第三方应建立动态评分和定期复审机制。
   • 接入清单应与实际产品版本和页面展示保持一致。

七、常见误区及踩坑提醒