最小必要怎么落地
最小必要不是一句口号，而是「收集范围与实现处理目的直接相关，且限于最小范围」的具体要求。落地方法很直接：把每个个人字段与它服务的业务功能一一对应，逐项论证必要性，给出不收集的影响与替代方案，并在功能变更时重新评估。判断难点不在技术，而在愿不愿意删掉那些「以后可能有用」的字段。
字段必要性评估表
字段必要性评估表
字段 | 关联功能 | 是否必需 | 不收集的影响 | 替代方案 | 结论
手机号 | 登录验证 | 是 | 无法验证身份 | 邮箱登录（可选） | 保留
精确位置 | 内容推荐 | 否 | 推荐精度下降 | 城市级位置或手动选择 | 降级采集
身份证号 | 实名认证 | 视场景 | 部分业务无法办理 | 无 | 限定场景使用
通讯录 | 好友推荐 | 否 | 推荐效果下降 | 手动邀请 | 不收集
设备标识 | 风控与统计 | 视目的 | 风控能力下降 | 匿名化统计口径 | 明确目的后保留基本信息
| 法律依据 | 个人信息保护法第六条（明确合理目的、最小范围） |
|---|---|
| 配套规定 | 常见类型移动互联网应用程序必要个人信息范围规定 |
| 核心动作 | 字段与功能绑定、逐项论证、定期复核、提供替代方案 |
| 证据形式 | 字段清单、评估记录、需求评审纪要 |
评估四问
- 这个字段服务哪个具体功能，去掉它功能真的不能用吗
- 这个功能对用户是基础功能还是可选功能，能否让用户选择
- 有没有侵入性更低的替代方式，例如粗粒度位置、系统相册选择器
- 收集之后保存在哪里、保存多久、谁能看到，是否都有必要
常见过度收集表现
| 表现 | 问题 | 改法 |
|---|---|---|
| 注册即索取通讯录 | 与注册功能无直接关系 | 改为使用时申请或不申请 |
| 拒绝授权就无法使用 | 把非必要信息与基础功能捆绑 | 基础功能不依赖非必要授权 |
| 后台持续定位 | 超出当前功能所需范围 | 改为使用时定位或粗粒度 |
| 预填身份证与银行卡 | 敏感信息不必要的留存 | 仅办理该业务时收集并加密存储 |
典型使用场景
- 产品需求评审：新增字段与埋点前先过评估表，避免上线后收敛
- 隐私政策核对：把政策中的收集清单与实际字段逐一比对
- 第三方 SDK 治理：排查 SDK 实际采集的字段是否超出声明范围
- 合规整改：被指出过度收集时，用评估表说明删改范围与理由
不同意收集非必要信息时，不得因此拒绝提供基本功能服务；常见类型应用另有专门的必要个人信息范围规定，优先按对应类型的清单执行。
评估只做一次是常见漏洞：新功能上线、SDK 升级、埋点调整都会引入新字段，评估表要作为需求评审的固定环节。
怎么把评估嵌进流程
单独做一次评估表容易流于形式，关键是把评估变成产品流程的固定环节：需求评审时同步提交字段清单与必要性说明，测试阶段核对实际采集行为是否与清单一致，上线前由合规岗抽查页面与 SDK 的申请时机。这样字段的必要性论证与实现不是两件事，收敛范围也不会被开发过程中的临时改动带偏。
拒绝授权时的处理原则
- 基础功能不依赖非必要授权：拒绝后仍能正常使用核心服务
- 逐个场景申请：用到定位、相册、通讯录时再申请，不在启动时一次性索要
- 说明用途：申请时给出具体理由，而不是只写「为了更好的体验」
- 留出替代路径：允许用户手动填写或使用粗粒度数据