82款App被通报 个人信息保护专项行动再加码

一、两轮通报接连落地，专项行动进入处置阶段

9月22日，国家网络安全通报中心发布通报：经国家计算机病毒应急处理中心检测，82款移动应用存在一项或多项违法违规收集使用个人信息情形。此次通报依据《网络安全法》《个人信息保护法》《网络数据安全管理条例》以及《App违法违规收集使用个人信息行为认定方法》，问题按12类情形分类列出，包括未明显提示隐私政策、向第三方提供个人信息未取得单独同意、无隐私政策等。按照惯例，相关运营者应在通报发布之日起的15个工作日内完成整改。

这已是三天内的第二次集中通报。9月20日，中央网信办通报30款App个人信息收集使用问题，其中包括9款未完整准确列明收集使用个人信息情况的应用、11款未提供有效账号注销功能的应用。

更早的8月19日，三部门公布专项行动阶段性成效：累计对2万余款App、SDK开展核查检测，督促4000余款完成合规整改，公开通报1100余款存在违法违规问题的App、SDK，并对400余款采取下架等处置措施。专项行动的政策源头是今年4月2日中央网信办、工业和信息化部、公安部联合发布的《关于开展2026年个人信息保护系列专项行动的公告》，治理范围覆盖App与SDK，并延伸至互联网广告、教育、交通、卫生健康、金融等重点领域。从通报整改到下架处罚，监管链条已经跑通。

二、12类问题背后的三个共性根因

把两轮通报的问题归并来看，共性集中在三个环节。

① 告知与同意流于形式。隐私政策藏在小字或二级页面里，个别应用甚至没有隐私政策；向第三方提供个人信息时不告知接收方名称、处理目的与范围，更谈不上取得单独同意。这类问题的判定标准在《认定方法》中已有明确条文，检测时通常一次即可命中。

② 权限与收集范围超范围。在无关场景索要位置、通讯录，调用麦克风与存储权限；扫码缴费、领取票券等功能强制要求注册登录、强制收集手机号。

③ 全生命周期管理缺位。不少应用上线多年却没有可用的账号注销入口，用户要求删除数据时没有路径；嵌入的第三方SDK回传了哪些字段，运营方自己也不清楚。

问题反复出现的根因并不复杂：研发流程里没有合规卡点，上线前不做个人信息合规检测；SDK供应链不透明，清单、版本与回传字段没有台账；运营阶段缺少数据资产清单，谁在收集什么、存多久、谁能访问都说不清楚。个人信息保护的技术难度并不算高，难的是把它变成固定的流程动作。

三、可直接执行的自查整改清单

对企业而言，下面这份清单可以直接当工作表用，指定一名整改责任人并留存过程记录即可推进。

建台账。把名下App、小程序、公众号、H5全部列出来，登记运营主体、负责人、收集字段、申请权限与嵌入的SDK，很多单位第一步就会发现应用数量比想象中多。

权限最小化。按功能申请权限，用户拒绝后核心功能仍然可用；不在无关场景索要位置与通讯录，不在启动时批量索取。

告知与单独同意。隐私政策在首次启动时显著提示；涉及第三方共享时，列出接收方名称、目的、方式和范围，并取得单独同意。

账号注销与删除闭环。应用内可完成注销，注销后按约定期限删除或匿名化，并留存操作记录，做到可核查。

SDK治理。建立SDK清单与版本台账，签署委托处理协议，明确数据字段与用途，定期核验是否超范围回传。

技术验证。用抓包核验数据实际流向与隐私政策是否一致，结合自动化合规检测工具做上线前与版本更新后的复测。

整改留痕。保留整改方案、修改记录与复测结论，一旦被通报，这些材料是15个工作日内完成整改并申请复测的关键。

四、对青海政企的落地建议

从青海本地的应用场景看，风险点集中在几个地方：州县医院的互联网医院与挂号小程序、校园类应用与教育平台、交通出行与ETC服务、景区门票与文旅小程序、各类政务便民小程序。它们共同的特点是外包开发比例高、上线后运维投入有限，第三方SDK由供应商选型，运营单位对数据流向掌握不足。

因此推荐三件事：第一，把个人信息合规与等保测评、数据安全风险评估合并开展，一次进场完成多项检查，对预算有限的单位尤其合适；第二，在采购与外包合同中明确SDK清单报备、数据不得违规出境、违规整改与赔偿责任，把合规要求前置到签约环节；第三，建立通报应对预案，明确一旦被通报，谁在两个工作日内出方案、谁改代码、谁做复测，避免15个工作日时限内手忙脚乱。