专项行动方向 7个 | 金融机构类型 6+类 | 重点查处问题 4大类 |
每一轮监管专项行动的背后,都是一次对行业合规红线的深度校准。 |
部门 | 职能方向 |
中央网信办 | 网络信息内容监管执法 |
工业和信息化部 | App / SDK 行业整治 |
公安部 | 违法犯罪专项打击 |
▶ 场景一: 调用用户通讯录,实际与贷款审批流程无直接关联,却以"识别欺诈关联人"为由申请权限 |
▶ 场景二: 在非授信场景下持续采集位置信息,频率超出业务必要限度,形成行为轨迹画像 |
▶ 场景三: 读取设备内安装的应用列表,用于推断用户征信状态,构成间接征信数据采集 |
▶ 场景四: 申请麦克风权限却未明确告知用途,存在环境音收集的法律风险 |
核心原则提示 「最小必要原则」不是形式上的合规条文,而是金融机构每一次权限申请都必须回答的核心问题: 没有这个数据,业务目标真的无法实现吗? ——《个人信息保护法》第六条 |
违规场景 | 风险级别 |
隐私政策中以"合作伙伴"统称,未具体列明第三方机构名称及数量,用户无法知情 | 高危 |
捆绑授权——将第三方数据共享与核心服务使用捆绑,不同意共享即无法使用App | 高危 |
合作方变更后未重新通知用户并获取同意,数据继续流向已变更的第三方 | 中危 |
SDK嵌套——合作SDK在未获用户知情的情况下独立上传数据至第三方服务器 | 需整改 |
▶ 当非人脸识别方式(如短信、密码、证件核验)已可实现身份验证目的时,不得将人脸识别设定为唯一验证方式 |
▶ 使用人脸识别前,必须向用户进行单独告知,并取得单独同意,不得纳入隐私政策一并授权 |
▶必须落实人脸识别技术应用安全管理相关要求,包括数据加密、访问控制、留存期 限 等 |
▶柜台、App等线上线下全场景均在治理范围之内,不以业务形态区分 |
违规场景 | 合规替代 |
作为唯一验证方式 | 短信验证码 |
无其他替代方案 | 密码验证 |
未履行单独告知 | 刷证件照核验 |
特别提示 人脸信息一旦泄露,无法像密码一样重置,其不可更改性使得安全风险是永久性的。这也是监管将其单独列明的根本原因。 |
维度 | 完备度 | 状态 |
制度文件层(隐私政策、数据分类规程) | 62% | 待完善 |
技术安全层(加密、去标识化、访问控制) | 48% | 较薄弱 |
安全保护措施(泄露应急响应机制) | 39% | 严重不足 |
人员管控层(第三方运维人员管控) | 31% | 严重不足 |
第一步 · 即刻启动 |
权限清单梳理与最小化评估 全面盘点 App、H5、小程序申请的所有权限,逐一验证其业务必要性。通讯录、位置、麦克风等高风险权限若无必要,应立即关闭或降低调用频次。重点检查 SDK 第三方权限调用情况。 |
第二步 · 2周内 |
第三方共享合规链路审查 梳理所有数据流转路径,建立第三方数据接收方台账,对照现行隐私政策逐一核查是否完成"告知+同意"闭环。对助贷、征信、催收等高风险外部合作方重点审查合同数据保护条款。 |
第三步 · 1个月内 |
人脸识别场景合规改造 梳理全流程人脸识别使用场景,为每个场景配备至少一种替代验证方式。更新用户单独告知弹窗和同意机制,完成人脸数据安全评估报告,并落实相应技术防护措施。 |
第四步 · 持续推进 |
个人信息保护内控体系建设 制定或修订个人信息保护管理制度、数据分类分级规程、数据访问控制规范及泄露应急预案。对技术运维外包人员实施权限最小化管控,建立全流程操作审计日志,完成年度个人信息保护影响评估(PIA)。 |
合规三要义 一、最小必要 — 每一次数据采集都必须能回答"没有它,业务无法运行" 二、知情同意 — 每一次数据共享都必须有清晰的告知和单独的同意 三、体系管控 — 制度、技术、人员三层防线缺一不可 |