30款App被通报,小程序整改怎样才算闭环?

“15个工作日内完成整改”，并报送整改情况——这是中央网信办2026年9月20日通报的要求。放到一张待签的电商小程序上线单上：隐私政策已改，组件和注销功能的复测栏却空着，你凭什么确认整改完成？

整改完成，要由实际行为和复测证据证明。 对业务、安全、法务而言，真正要对齐的是数据流、最小必要、SDK、授权与留痕这5个环节，而非一份文档。

中央网信办《关于30款App个人信息收集使用问题的通报》明确，检测对象为App（含小程序）。它列出4类问题：未公开规则6款，强制或频繁索要非必要权限4款，未完整准确列明收集使用情况9款，未提供有效账号注销功能11款。

本次给出的是具体检测发现、整改报送要求和后续核查安排。不能解读成“小程序首次纳入监管”，更不能据此认定所有小程序违法。本文的5个治理环节，也不是通报的分类。

我不同意“更新隐私政策就算完成整改”。通报中的非必要权限和注销问题，都要靠功能行为验证。只让法务改文案，省下的是联调时间，留下的是没有复测的业务风险。

业务负责人应把问题对应到功能与责任人。未被通报的团队可据此自查，不适用本批整改期限。

▲ 文档已更新，不能替代功能复测。

▎告知要对应数据去向，不能只对应页面

《个人信息保护法》第17条要求处理前告知目的、方式、种类、保存期限等；第19条要求，除法律、行政法规另有规定外，保存时间应为实现目的所必要的最短时间。

落实到小程序，产品和研发要从功能往下查：哪个动作触发哪个字段，经什么接口到业务后端，又交给谁、保存多久。安全核请求，法务核披露。客户端没有直连第三方，不等于后端没有转发。

没有数据流基线时，先画主要功能的数据流，再补分支；不能将尚未核验的分支当作已通过。域名只能提供线索，不能替代接收主体认定；这一步需要研发查后端，单靠客户端检测报告不够。

▎下单需要地址，不等于浏览也需要

第6条要求收集范围最小必要。第13条区分同意、履约必需等处理依据；第16条规定，不得因拒绝或撤回同意而拒绝服务，但处理属于服务所必需的除外。

对前述实物电商场景，配送需要地址，浏览商品未必需要。营销统计也不能只因接在下单接口里，就被归入履约必需。产品须逐字段写清用途和不用它的后果，法务确认依据。

对不依赖该字段的功能，要保留拒绝后的可用路径。代价是多测一个分支；不能反过来把“所有字段都可以拒绝”写成通用规则。

▎SDK列了名字，还要确认它替谁处理

SDK即软件开发工具包。第21条要求约定委托处理事项并监督受托人；第23条对向其他个人信息处理者提供信息规定了告知、单独同意要求，具体适用还须结合第13条的处理依据。共同决定目的和方式的，还应按第20条约定双方责任。

因此，采购与法务不能只收供应商承诺书。要根据谁决定处理目的、方式，分清委托、共同处理或向其他处理者提供等关系，再让研发确认组件版本、配置与发送字段。涉及委托、对外提供等情形，第55条还要求事前影响评估。

组件清单只是入口，合同角色、声明用途与实际去向必须对得上。 小程序插件、业务组件、宿主能力和后端转发应分别归属，不能把宿主App全部SDK都算到小程序头上。分类核验费工，但能避免查错对象。

▲ 客户端没有直连第三方，也要核验后端是否转发。

第14条要求基于同意的处理获得知情、自愿、明确的同意；处理目的、方式、种类发生变更时，应重新取得同意。第15条要求提供便捷的撤回方式。

测试不能止于弹窗截图。研发和测试要核验首次进入、拒绝、同意、撤回后的实际行为。系统权限、小程序接口授权与个人信息处理同意不是一回事；也不是同意前出现任何网络请求都必然违规，要看请求处理了什么及其依据。

微信《小程序隐私协议开发指南》明确：接口涉及的信息须在后台指引中声明，且用户同意状态须同步微信。更新配置后，原有接口与新增接口的同步要求不同。因此，仅凭旧账号还能调用原接口，不能判定新版本授权正常。

验收应分别记录系统权限、微信侧隐私同意和业务侧同意状态。按该指南，可用wx.getPrivacySetting查询微信侧待同意状态；业务后端的记录要另查。清本地缓存不等于重置这些状态，增加新用户与老用户升级用例，才有可复现的结论。

注销还要连到客服受理、后端删除和第三方处理结果。第50条要求便捷的权利申请受理、处理机制；第47条规定删除条件及法定保存期限未届满等情况下的处理限制。

所以，注销按钮可点击不等于功能有效，也不能承诺注销后立即删掉全部订单数据。法务先明确依法保留的范围和期限，研发验证其余数据的处置。属于第47条规定的保留情形，应停止存储、安全保护之外的处理。

第51条要求建立内部管理制度和操作规程，第54条要求定期合规审计。把它们落到发布环节，可以用受控工单串起问题编号、责任人、修复变更、复测结论和放行记录，不必先买一套新系统。

证据包应关联数据流、组件配置、告知版本、授权测试记录及注销结果。同一问题编号下，保留修复前后的操作步骤、请求差异和复测人；截图不能代替行为证据。

前端、后端、组件版本和远程配置都要能定位。前端版本没变，后端转发规则仍可能已变。上述是将管理义务落到发布的治理建议，并非法条规定的统一证据格式。

业务确认用途，研发提交修复，安全或测试验证行为，法务核依据和告知，发布责任人据此签字。字段、目的、组件或接收方变更时，要复测受影响路径；纯文字修订则按影响确定范围，不必每次全量重扫。

复测未通过，相关功能就不能按“已整改”放行。 内部例外审批不能豁免法定义务。上线后还应验证实际配置；发现行为与复测不符，重新开问题单，不能沿用旧结论。

留痕也有边界。使用测试账号、脱敏请求，限制访问和保存期限。第56条的“至少保存三年”针对影响评估报告和处理情况记录，不是要求所有截图、抓包、业务日志一律存三年。

▲ 复测未通过不放行，上线行为不符就重新开单。

2026年9月20日是这份通报的发布日期，不是新法生效日。通报相关运营者应按“发布之日起的15个工作日内”完成整改并报送。涉及节假日调休和计期口径，具体截止日应向主管部门确认，不能直接加15个自然日。

其他团队应把核验接入下一次相关需求和发布。存量系统尚无台账的，先补基线，再按变化复测，关键用户路径仍要贯通验证。后端独立发布、远程配置调整也须纳入，不能只盯小程序提审。

按通报期限与内部治理节点分别安排：

下一次后端单独改了数据接收方，你们现有流程会自动触发隐私复测吗？若不会，留言写下这张变更单现在由谁签字。

— END —