2026个人信息保护专项行动解读:App与SDK合规治理重点及企业应对

中央网信办、工信部和公安部于2026年4月2日联合发布了关于开展2026年个人信息保护系列专项行动的公告（以下简称“公告”），公告明确将进一步深入治理App、SDK等服务产品以及互联网广告、教育、交通、卫生健康、金融等重点领域违法违规收集使用个人信息典型问题。我们将以系列文章分别进行解读，为大家逐条分析公告的每个合规要点，揭示未言明的潜在要求，以及最重要的——提供能经受监管考验，同时符合企业实际的合规建议。

为便于阅读，此次系列文章体例为“要点+分析”，读者可以根据要点决定是否细读，节约大家时间。本篇将解读App、SDK违法违规收集使用个人信息专项治理。

*本文篇幅有限，如有遗漏或想进一步讨论的事项，十分欢迎后台联系，我们会专门答复或整理后成文发布。

*我们根据相应法律法规、行业标准和实务经验起草了隐私政策模板，可结合本文内容以制定适配的隐私政策。欢迎后台留言“App合规”领取。

要点1：App不仅包含手机端的应用程序，还包含小程序。

公告第1项是针对App、SDK违法违规收集使用个人信息的专项治理，治理对象为常见类型App和SDK。其中App不限于手机上的运行的应用程序，还包括小程序，原因有二：

1.根据《常见类型移动互联网应用程序必要个人信息范围规定》第2条和《信息安全技术移动互联网应用(APP)收集个人信息基本要求(GB/T 41391-2022)》第3.1条，移动互联网应用程序（mobile internet application），App包括移动智能终端预置、下载安装的应用软件，基于应用软件开放平台接口开发的、用户无需安装即可使用的小程序。

2.工信部定期发布的“关于侵害用户权益行为的APP（SDK）通报”中，已经有将微信小程序作为通报对象的案例。

此外，我们在涉app企业的IPO上市项目中，监管至少在2022年就已经将微信小程序、支付宝小程序与手机App一并作为合规问询对象。

综上，2026公告中的治理对象中的App不仅包含手机应用程序，还包括小程序。

要点2：正确有效地展示（公开）个人信息收集使用规则的关键在于展示方式应符合监管要求且易于访问和阅读；App和SDK的展示方式略有不同；涉及未满14周岁未成年人个人信息处理的，需制定专门的儿童个人信息保护规则。

由于App和SDK的功能定位、数据处理场景以及触达用户的方式不尽相同，法律法规以及监管实践对于两者展示个人信息收集使用规则的要求也略有不同。

一、App展示方式合规要求

1.App首次运行时或用户注册时应通过弹窗、突出链接、附件等主动且明显的方式提示用户阅读隐私政策等收集使用规则。

2.应保证在应用商店、App首次隐私弹窗、App界面内均有展示，且注意核查三处的隐私政策版本是否一致。

3.隐私政策等收集使用规则难以访问，如进入App主界面后，需多于4次点击等操作才能访问到；避免使用不明显的方式展示隐私政策链接，导致用户不易发现隐私政策，例如采用与背景颜色相近的字体、刻意缩小字号、弹出键盘遮挡、置于边缘等为不明显方式展示隐私政策链接。

4.尽可能在界面的固定路径展示隐私政策（或其链接），以便用户随时访问和获取，避免仅在注册/登录界面展示隐私政策链接，或只能以咨询客服等方式查找隐私政策等情形。

例1：通过“我--设置--关于”或者“我的--设置--隐私”等用户熟悉路径展示隐私政策，不频繁变更展示隐私政策的路径。

例2：在首次展示隐私政策时，宜说明查找隐私政策的方法、路径。

5.避免隐私政策等收集使用规则难以阅读，如文本字号过小、颜色与背景色相近、行间距过密、模糊不清，或未提供简体中文版等；隐私政策内容使用标准化的数字、图示，采用通用的语言习惯，避免误用概念、术语或存在有歧义的语句等

6.隐私政策以单独成文的形式发布，而不是作为用户协议、用户须知等文件中的一部分存在。

注：如果因展示条件等特殊原因使用用户协议、用户须知等文件描述个人信息收集使用规则，则尽可能显著标识并以连续篇幅呈现。

7.App隐私政策页面应提供一键保存功能；

8.如存在涉及收集使用儿童个人信息相关业务功能的，需制定针对儿童的个人信息保护规则

二、SDK展示方式合规要求

1.SDK 运营者应在官方网站、开源社区或集成文档中提供隐私政策,并在隐私政策中声明 SDK,所具有的全部功能和个人信息处理规则,告知的信息应完整、准确、及时,不存在故意隐瞒、欺骗等行为; 查询方式应清晰、便捷。

2.避免隐私政策等收集使用规则难以阅读，如文本字号过小、颜色与背景色相近、行间距过密、模糊不清，或未提供简体中文版等；隐私政策内容使用标准化的数字、图示，采用通用的语言习惯，避免误用概念、术语或存在有歧义的语句等

3.隐私政策页面应提供一键保存功能；

4.若SDK涉及处理不满十四周岁未成年人的个人信息，则应制定专门的个人信息处理规则。

要点3：账号注销可以通过用户自助功能实现，也可以通过其他方式实现；核心是实现方式要足够便捷、有效和及时。对于SDK，一般情况下不涉及账号注销，但应向用户提供个人信息删除功能或渠道。

一、关于App的账号注销功能要求

2026公告对于帐号注销要求“提供有效注销用户账号功能”，根据我们的项目经验结合监管实践案例，我们理解监管并非强制要求App内部要内置自助式的账号注销功能（即用户无需联系客服、无需人工审核、无需线下提交材料，就可以在产品内自行完成账号注销，并且后台自动删除用户相关数据的功能）。合规实践上，可以通过其他方式实现账号注销，例如：

1.通过在隐私政策及App相应页面展示注销账户的联系方式（例如客服电话、邮箱），用户通过联系方式申请注销。

2.在App中设置注销页面，用户在页面中填写申请。

需要强调的是，监管实践更关注的不是实现注销的方式，而是注销申请是否便捷、有效和及时。因此在完善账号注销合规时应遵循下列法律法规和监管实践要求：

1.不应为更正、删除个人信息或注销用户账号设置不必要或不合理条件。例如：

（1）用户难以找到注销入口；

（2）注销操作流程非常复杂不易操作、注销过程进行身份核验时，要求用户提交超过App 注册、使用时收集的个人信息类型（如注册使用时未提供身份信息，但是注销时要求提供手持身份证照片、绑定银行卡等）；

（3）对于采用同一账号注册登录多个App 的情形，注销单个账户视同注销多个产品或服务；

多个App共用一个账号体系时，单个App注销建议： 

①　用户可退出或注销单个App，且不影响无必要业务关联App的正常使用； 

②　提供解除单个App用户账号使用关系等措施实现注销，并对该App账号以外其他个人信息进行删除； 

③　如多个App之间存在必要业务关联而无法拆分账号，需在注销前向用户详细说明账号关联的应用、注销条件、注销后果等信息。 

注：存在必要业务关联，是指如一旦注销某个 App 的账号，将会导致其他 App 的必要业务功能无法实现或者服务质量明显下降的。另外需注意，产品或服务没有独立的账户体系的，可采取对该产品或服务账号以外其他个人信息进行删除，并切断账户体系与产品或服务的关联等措施实现注销。

（4）要求用户填写精确的历史操作记录作为注销的必要条件等。

2.应及时响应用户相应操作，需人工处理的，未在承诺时限内（承诺时限不得超过15个工作日，无承诺时限的，以15个工作日为限）完成核查和处理。

3.用户注销账号后，停止对用户个人信息的收集和使用，及时删除其个人信息或进行匿名化处理。因法律法规规定需要留存个人信息的，将其隔离存储，不能再次将其用于日常业务活动中。

4.注销时因验证用户身份所收集的个人敏感信息，完成用户身份验证后立即删除或匿名化处理

5.避免用户在App前台注销操作已执行完毕，但App后台实际并未完成注销和数据删除。

6.制定并公开账号注销条款，明示账号注销的条件、后果、方法、流程等信息。注销条款可作为个人信息保护政策的章节，也可制定单独的注销协议。

二、关于SDK的个人信息删除功能或渠道的要求

一般情况下，SDK并不涉及用户账号注销，但是我们理解监管对于账号注销的要求本质是个人信息删除权的延伸。因此虽然SDK不太涉及账号注销，却涉及向用户提供个人信息删除的功能或渠道，具体法律法规和监管实践要求如下：

1.SDK 运营者应向 App运营者提供个人信息删除机制,最终用户可通过 App行使个人信息删除权利,SDK 运营者应在接收到 App运营者关于最终用户的个人信息删除的请求后,在服务器端删除其收集的个人信息或做匿名化处理。

2.App运营者停止接入SDK并通知SDK运营者后，SDK运营者应停止继续通过该App收集个人信息,若SDK 运营者存在收集个人信息的，应按照双方合作协议中约定的个人信息处理要求和最终用户的授权范围,在服务器端删除其收集的个人信息或做匿名化处理。

3.SDK停止运营后,应在服务器端删除其收集的个人信息或做匿名化处理。

4.SDK运营者应通过官方网站、开源社区、公共仓库、隐私政策文本或以其他方式提供个人信息删除的渠道。

要点4：建立、公布个人信息安全投诉举报渠道的实现方式简单，企业内部的制度和SOP构建能够有效响应投诉才是关键。

建立、公布个人信息安全投诉举报渠道的实现方式简单，可以在隐私政策、官网及App相应页面公布电子邮件、电话、在线客服、在线表单、即时通讯账号等受理方式。

个人信息安全投诉举报渠道的关键在于企业内部能够有效响应接到的举报内容，因此企业应制定相应的处理个人信息安全投诉举报的内部制度，明确企业内部各部门的职责并且制定部门联动SOP，确保相关的投诉举报问题可以有效及时地响应可以客服前端受理。具体应注意以下事项：

1.企业应妥善受理用户关于个人信息相关的投诉、举报，并在承诺时限内（承诺时限不得超过15个工作日，无承诺时限的，以15个工作日为限）受理并处理。

2.投诉举报涉及网络安全事件的，应按照网络安全事件相关法律法规要求进行响应。

注：企业应按照相应法律法规结合企业自身情况（所属行业、数据处理情况、商业模式等）制定网络安全事件应急预案，并对员工进行宣贯和培训。

要点5：完整准确告知收集使用个人信息情况，关键在于隐私政策内容是否完整准确和交互设计是否合规。

一、隐私政策合规要点

目前行业实践，不论App还是SDK，主要还是依赖通过隐私政策向用户告知收集使用个人信息的情况，因此，隐私政策的内容是否完整和准确，是合规的关键。

（一）App隐私政策的合规要点

1.对App运营者基本情况进行描述，至少包括组织名称、注册地 址或常用办公地址、个人信息保护工作机构或相关负责人联系方式。 

2.说明隐私政策的发布、生效或更新日期。

3.说明收集使用个人信息的目的、方式、范围，具体应：

（1）完整、清晰、区分说明各业务功能所收集的个人信息。宜根据用户使用习惯逐项说明各业务功能收集个人信息的目的、类型、方式，避免使用“等、例如”等方式不完整列举。

注：业务功能通常是指App为面向用户的具体使用需求所提供的一类完整的服务类型，如地图导航、网络约车、即时通信、网络支付、新闻资讯、网 上购物、短视频、快递物流、餐饮外卖、交通票务、婚恋相亲、房屋租售、求职招聘、网络借贷等。 

（2）使用Cookie等同类技术（包括脚本、Clickstream、Web 信标、 Flash Cookie、内嵌 Web 链接等）收集个人信息时，简要说明相关机制，以及收集个人信息的目的、类型。 

（3）如嵌入的第三方代码、插件（如SDK）收集个人信息，说明第三方代码、插件的类型或名称，以及收集个人信息的目的、类型、方式、使用的系统权限。

4.对个人信息存放地域（境内、境外哪个国家或地区）、存储期限（法律规定范围内最短期限或明确的期限）、超期处理方式进行说明。

5.如果将个人信息用于用户画像、个性化展示等，说明其应用场景和可能对用户权益产生的影响。

注：如部分业务功能不涉及用户画像、个性化展示，可在规则中明确说明。

6.如果存在个人信息出境情形，说明出境个人信息类型并显著标识。例如可采用字体加粗、标星号、下划线、斜体、不同颜色等显著标识方式。

7.对个人信息保护方面采取的措施和具备的能力进行说明。

8.如果存在个人信息对外共享、转让、公开披露的情况，说明以下内容：①对外共享、转让、公开披露个人信息的目的；②涉及的个人信息类型；③接收方类型或身份。 

9.对以下用户权利和相关操作方法进行说明：①个人信息查询；②个人信息更正；③个人信息删除；④用户账号注销；⑤撤回已同意的授权。 

10.至少说明以下一种投诉、举报渠道：①电子邮件；②电话；③在线客服；④在线表单；⑤即时通信账号。 

11.隐私政策等收集使用规则如发生变动，应及时告知用户最新情况。

12.应以简洁、清晰、易懂的方式，向用户提供隐私政策摘要。

13.有能力的企业，宜建立已收集个人信息清单和与第三方共享个人信息清单（“双清单”）

（二）SDK隐私政策的合规要点

1.SDK收集的个人信息的目的、方式、范围;

2.SDK申请的系统权限和申请目的;

3.SDK收集的个人信息的保存期限、被停止嵌入后的个人信息处理方式;

4.个人信息安全责任和保护措施;

5.SDK是否存在热更新机制;

6.SDK是否存在自启动、关联启动;

7.SDK收集的个人信息是否涉及向境外提供;

8.SDK自行或协助App响应用户个人信息权利请求的措施。

二、交互设计合规要点

除却隐私政策，通过推送消息、邮件、弹窗、红点提示等方式，向用户告知个人信息处理情况亦是合规关键，具体如下：

1.App应设置有隐私政策更新弹窗或站内信功能，在隐私政策有重大更新时弹窗告知用户，并根据适用的合法事由采用不同的告知方式。

-基于同意：提供弹窗，并提供同意和拒绝按钮

-基于其他合法事由：提供弹窗并提供“好的”、“已知晓”按钮，或通过站内信告知。

2.App在首次安装启动时是否通过弹窗等明显方式，将隐私政策及用户协议进行展示。

3.在申请打开可收集个人信息权限时，通过显著方式同步告知用户其目的，对目的的描述明确、易懂。例如，可采用弹窗提示、用途描述等显著方式告知。

注：在特殊个人信息处理活动场景下，合规要求更加严格，因此告知的内容和获取单独同意的交互设计也有更多要求。详见要点6

要点6：应用程序的交互设计是否合法合理是用户“同意”是否有效的关键，特殊个人信息处理活动的单独同意获取是合规重点。

目前绝大多数App已经能够做到在首次运行乃至每次用户登录时，通过弹窗或者用户登录界面展示隐私政策，并提供勾选框由用户勾选同意，从而达到获取用户同意以处理用户个人信息的法律要求。但是，随着监管合规要求的水位逐年增加，这种“一揽子同意”的做法已经不足以满足合规要求，监管开始针对《个人信息保护法》第14、23、25、26、29和39条所要求的单独同意，提出了新的合规要求，即App在进行特殊个人信息处理活动，应通过弹窗或专门页面等方式向用户专门告知并获取额外的同意，以满足单独同意的要求。仅通过隐私政策中列明特殊个人信息处理活动，用户仅在App首次运行或注册登录时同意隐私政策，不足以构成用户同意App对其个人信息进行特殊个人信息处理。

一、需要获取单独同意的特殊个人信息处理活动

1.个人信息处理者向其他个人信息处理者提供其处理的个人信息；

2.个人信息处理者公开其处理的个人信息；

3.在公共场所安装图像采集、个人身份识别设备所收集的个人图像、身份识别信息，个人信息处理者拟用于维护公共安全之外的目的；

4.处理敏感个人信息；

5.向境外提供个人信息。

二、如何获取单独同意？

“告知—同意”规则已在《中华人民共和国网络安全法》《中华人民共和国民法典》《中华人民共和国个人信息保护法》等法律中得到明确规定。基于上述规定，个人信息处理者在处理个人信息时，应依法履行告知并取得同意的义务。对于需要单独同意的特殊个人信息处理活动，告知和获取单独同意的具体要求更加严格，具体如下：

1.告知的具体要求

（1）在进行特殊个人信息处理活动前,应采用单独弹窗、短信、填写框、动画、转至单独提示界面和语音播报等方式向个人进行告知

（2）除了向用户告知《个人信息保护法》第17条规定的内容，还应按法律法规对各特殊个人信息处理活动的要求向用户告知相关内容：

①　个人信息处理者向其他个人信息处理者提供其处理的个人信息的，应告知用户接收方的名称或者姓名、联系方式、处理目的、处理方式和个人信息的种类。

②　个人信息处理者公开其处理的个人信息的，应告知公开的目的、公开的个人信息范围、公开对个人信息主体影响分析及可能采取应对措施。

③　在公共场所安装图像采集、个人身份识别设备所收集的个人图像、身份识别信息，个人信息处理者拟用于维护公共安全之外的目的：如是用于特殊个人信息处理活动之目的，则见本节相应内容；如用于非特殊个人信息处理活动之目的，则应告知《个人信息保护法》第17条规定的内容；涉及多人的，在处理前，需逐一向每个人告知。

④　处理敏感个人信息的，应应告知个人信息处理者的名称或姓名、联系方式等基本情况,敏感个人信息的处理目的、处理方式和必要性,敏感个人信息的种类、保存期限和对个人权益的影响,用户行使个人信息权利的方式和途径。

⑤　向境外提供个人信息的，应告知境外接收方的身份、联系方式、处理目的、处理方式，个人信息的种类、保存时间、保存区域（至少具体到国家或地区）以及个人向境外接收方行使相关权利的方式等内容

（3）持续进行特殊个人信息处理活动的，例如持续收集敏感个人信息的,宜提供持续提示或间隔提示机制。

注：关于“持续收集”，指在用户使用服务期间不间断地连续收集用户信息,如录音、录像和连续的位置信息等。如出行导航类需持续收集个人信息主体地理位置信息的,以浮窗、弹窗、语音、振动和状态栏图标等形式提醒个人信息主体当前地理位置正在被收集。

2.单独同意的具体要求

（1）获取单独同意的方式,可由用户主动完成填写提交,也可通过设置独立页面、电话和短信等向用户进行告知并通过个人点击或分项勾选等肯定性动作作出同意表示，独立页面的形式例如：

①　独立的弹窗；

②　下滑查看详情的嵌套网页；

③　跳转到另一页面给出增强告知；

④　单独的隐私政策，如未成年人个人信息处理规则、第三方传输数据授权文件、人脸识别同意书等。

（2）多项敏感个人信息处理活动,应按处理目的和业务功能为用户提供单独同意机制，即应做到“一场景一告知一同意”。

（3）单项敏感个人信息被用于多个处理目的或业务功能的,不应捆绑取得同意，即单项敏感个人信息仅用于单项目的或业务功能，获得用户单独同意。如果App内存在多个业务会收集使用精确地理位置信息的业务，比如实时导航和匹配最近门店，在实际收集时，不能一次性收集用户的身份信息进行。两个业务应在分别进行时单独向用户告知并获取同意。

要点7：什么情况或被认为是强制用户同意？优化交互设计，提供游客模式和撤回同意功能是避免被认定为强制用户同意收集非必要个人信息的有效方案。

一、强制用户同意的情形有哪些？

强制用户同意收集非必要个人信息，本质是违反法律要求的“合法、正当、必要” 原则，侵害了用户的自主选择权，典型情形包括：

1.捆绑授权

捆绑授权是典型的强制用户同意收集非必要个人信息的典型，具体表现包括：在首次启动或注册时，统一要求用户授权多个权限，但其中部分权限与当前服务无直接关系；以“一揽子协议” 形式，强制用户一次性同意所有当前及未来可能的信息收集用途；要求用户一次性同意收集所有业务功能所需个人信息，不区分必要与非必要。

2.不同意收集非必要信息即拒绝提供服务

如果用户不同意提供非必要信息，App直接拒绝提供任何服务，包括其基本功能服务。常见形式包括：

（1）App首次运行时，App存在不给权限不让用的情形。即App安装和运行时，向用户索取与当前服务场景无关的权限，用户拒绝授权后，应用退出或关闭。

注：除App整体退出外，部分场景下未授权权限无法使用服务的仍属于违规。例如：添加收货地址时必需授权位置权限才能进行添加。

（2）用户不同意App提供的“一揽子协议”，App直接禁止注册、登录或使用主要服务。

（3）强制填写非必要信息的情况（如注册账号时强制填写生日、兴趣爱好、婚姻状况、教育经历等）。

3.默认勾选

App在注册/登录界面、收集使用个人信息界面展示隐私政策或个人信息处理协议时，默认勾选了“同意”勾选框。

4.静默/ 隐蔽授权

（1）App未经用户同意更改其设置的可收集个人信息权限状态的设置。如App更新后自动调整用户的位置权限为打开状态等。

（2）App在静默状态下（包括后台运行）、自启动或被关联启动后，未向用户提供服务且未告知用户信息处理的目的，却收集用户的个人信息（如设备信息、传感器数据等），或读取用户公共存储空间的数据（如相册、文件、录音等）

（3）App在首次启动时，用户同意隐私政策前，存在任何收集用户个人信息的情形。常见情况包括收集应用列表、唯一设备识别码（IMEI、IMSI、Android ID）等。

二、如何避免被认定为强制用户同意？

1.如何避免被认定捆绑授权

目前监管和司法实践并不绝对禁止在App首次启动或运行时展示一揽子协议形式的隐私政策，通过用户点击同意获取用户的事前概括同意，监管和司法判例都是允许的。但是，app还应同时做到以下事项：

（1）App设置有授权管理界面，对于个性化推荐、系统权限、商业广告管理等较为敏感的个人信息处理场景，向用户提供便捷的拒绝自动化推荐选项，对用户个人信息权益保障提供事后选择机制；

（2）对于需要单独同意的个人信息处理场景（见要点6），提供单独的弹窗或界面获取用户单独同意。

2.如何避免被认定为”不同意收集非必要信息即拒绝提供服务“

（1）App安装和运行时，不向用户索取与当前服务场景无关的权限，用户拒绝授权后，不会强制退出或关闭，用户仍可使用不需要权限的基础功能。

（2）用户不同意App提供的“一揽子协议”，App提供游客模式（未登录状态可浏览内容，区别于浏览模式/基本功能模式）。

（3）对于面向C端的App，不强制填写非必要信息的情况（如注册账号时强制填写生日、兴趣爱好、婚姻状况、教育经历等）；对于面向B端或供应商的App，如加盟商服务App等，出于业务管理需要，可以强制进行身份信息填写和身份验证。

3.如何避免默认勾选

要求负责App设计和运营的技术人员检验App，确保App在注册/登录界面、收集使用个人信息界面展示隐私政策或个人信息处理协议时，不会默认勾选“同意”勾选框。

4.静默/ 隐蔽授权

（1）要求负责App设计和运营的技术人员检验App，确保App未经用户同意时不会更改其设置的可收集个人信息权限状态的设置。尤其注意App更新后不会自动调整用户的位置权限为打开状态等。

（2）要求负责App设计和运营的技术人员检验App，App在静默状态下（包括后台运行）、自启动或被关联启动后，除非后台运行仍在向用户提供服务或已告知用户信息处理的目的，不应收集用户的个人信息（如设备信息、传感器数据等），或读取用户公共存储空间的数据（如相册、文件、录音等），重点排查App内嵌的SDK收集情况，有时候谈判地位强势（例如市场占有率大的SDK）的SDK会胁迫的App运营商突破必要原则，相关App运营商请注意沟通留痕以及勇敢向SDK运营商提出合规警示。

（3）App在首次启动时，用户同意隐私政策前，不得初始化任何可收集个人信息的API或第三方SDK；常见情况包括收集应用列表、唯一设备识别码（IMEI、IMSI、Android ID）等。

要点8：如何界定必要个人信息，如何界定超出必要范围（个人信息类型、频率、数量、精度等）收集使用个人信息，有相应法律法规以及行业标准。

界定“必要个人信息”和“超出必要范围收集使用个人信息”，在法律法规、行业标准和监管执法的不断完善下已经有比较完整的规则框架，但具体实践中还需要遵循最小必要原则，结合业务功能、处理目的以及对个人权益影响程度综合判断，而不是对条文的生搬硬套或者企业自行其是。

何为必要个人信息？根据《常见类型移动互联网应用程序必要个人信息范围规定》第3条和《信息安全技术移动互联网应用(APP)收集个人信息基本要求》(GBT 41391-2022) 第3.8条，必要个人信息，是指保障App基本功能服务正常运行所必需的个人信息，缺少该信息App即无法实现基本功能服务。

何为必要范围？狭义上的个人信息必要范围就是指个人信息的类型，例如《常见类型移动互联网应用程序必要个人信息范围规定》第5条中关于常见类型App的必要个人信息范围的规定，只列出了个人信息的类型。广义上的必要范围，根据《信息安全技术移动互联网应用(APP)收集个人信息基本要求》第6.1b，范围除了个人信息的类型还涉及收集个人信息的频率、数量、精度等。

一、如何界定必要个人信息

界定必要个人信息最重要的两个依据是《常见类型移动互联网应用程序必要个人信息范围规定》第5条和《信息安全技术移动互联网应用(APP)收集个人信息基本要求》(GBT 41391-2022) 附录A，两个文件给出了常见服务类型App的基本业务功能和必要个人信息范围，以及必要个人信息的使用要求。对于界定“基本功能服务”的方法，可参照GB/T 35273-2020《信息安全技术 个人信息安全规范》5.3 节及其附录C的规定。同时也可参考《网络安全实践指南 —移动互联网应用基本业务功能必要信息规范》（TC260-PG-20191A）。

此外，除了基于app基本功能服务类型角度去判断必要个人信息，同时也可以从个人信息类型本身去判断，具体方式可以参考系列标准《APP收集使用个人信息最小必要评估规范》，该系列标准共有17篇，并且还在陆续发布，除了第一篇总则，余下每篇分别针对一个个人信息类型，列出了其信息细分类型和典型使用场景，并且对该类个人信息在个人信息全生命周期中如何做到遵循最小必要原则给出了指导，目前包括的个人信息类型有：位置信息、图片信息、终端通讯录、设备信息、软件列表、人脸信息、录像信息、短信信息、录音信息、通话记录、好友列表、传感器信息、应用日志、房产信息、交易记录、身份信息。

App还绕不开一个问题，即调取系统权限。按照目前监管实践，App如调取非必要系统权限，也会被认定为收集非必要个人信息。除了按照前文检验相应系统权限所对应的个人信息类型是否匹配对应的基本服务类型外，还可以参考《网络安全标准实践指南 —移动互联网应用程序（App）系统权限申请使用指南》（TC260-PG-20204A），该标准针对各个手机系统权限，给出了对应的必要场景以及对应的业务功能。

二、如何界定必要范围

前文已说明，所谓必要范围，指的是个人信息的类型、频率、数量、精度。关于个人信息类型，即判断是否为必要个人信息，前文已论述。余下的个人信息收集频率、个人信息数量和个人信息精度的必要性判断，核心的要求本质还是最小必要原则的延申，收集个人信息的频率、数量、精度的把握应当采取对个人权益影响最小的方式，并限于实现处理目的的最小范围，不得过度收集个人信息。以收集个人信息的必要频率为例，如何不超过必要频率收集个人信息，应做到：

1.权限申请请求应有合理频率

如用户明确拒绝App业务功能所需权限，App不应频繁申请系统权限干扰用户正常使用，除非由用户主动触发功能，且没有该权限参与此业务功能无法实现，“频繁”的形式包括但不限于:

（1）单个场景在用户拒绝权限后，48小时内弹窗提示用户打开系统权限的次数超过1次;

（2）每次重新打开App或使用某一业务功能时，都会向用户索要或提示用户缺少相关系统权限，

2.App自动采集个人信息的频率应是实现App的业务功能所必需的最低频率，以下示例供参考：

不同场景下App收集个人信息的频率参考

要点9：实务中在具体数据处理场景中，是否必要亦有可以不生搬硬套法律法规以及行业标准的讨论空间。

在实务中，对于具体数据处理场景中“是否属于必要”的判断，通常并非一个可以机械套用法律条文、监管规定或行业标准后即可直接得出结论的问题，而是具有相当程度的事实判断空间、业务解释空间与合规论证空间。法律法规及行业标准固然提供了重要的判断依据和底线要求，但其规定往往具有原则性、概括性，难以穷尽所有复杂、多变且快速迭代的真实业务场景。因此，在实践操作中，企业与法律顾问通常需要结合具体处理目的、产品功能逻辑、用户合理预期、技术实现路径、替代方案可行性、数据敏感程度、对个人权益影响程度以及行业惯例等因素，进行综合判断，而非简单采取“法条未明确允许即禁止”或“行业普遍这么做即当然必要”的僵化理解。

例如，同样是收集位置信息，在导航服务中持续精准定位可能属于核心必要信息，而在普通电商应用中则未必当然必要；同样是收集联系人信息，在社交推荐功能中可能具有一定业务合理性，但仍需进一步论证是否存在侵入性更低的替代方案。也就是说，“必要性”判断往往与具体功能场景高度绑定，需要放在特定语境下分析，而不能脱离业务实际抽象讨论。

从合规治理角度看，这种“讨论空间”并不意味着企业可以任意扩大解释范围，而是意味着企业可以在合法、正当、最小必要原则框架内，通过充分的内部评估和外部律师论证，对数据处理行为的必要性进行合理说明。我们在多个辅助企业进行App合规评估的项目中也发现，监管越来越关注企业是否能够证明其收集使用行为与处理目的之间具有直接关联、是否超出用户合理预期、是否存在更少侵扰的替代方案，以及是否采取了透明告知、权限分级、用户自主选择等配套机制。

根据我们团队多年数据合规经验，实务中的关键并不只是寻找一条明确规定来“套答案”，而在于建立一套可解释、可举证、可复核的必要性判断机制：既能够回应业务发展的现实需求，也能够在监管问询、用户投诉或争议发生时，证明相关数据处理行为具有充分的合法性与合理性基础。

本文依据及参考的相关法律法规、规范性文件、标准及案例如下：

1.《移动互联网应用程序信息服务管理规定（2022）》

2.《常见类型移动互联网应用程序必要个人信息范围规定》

3.《关于开展App违法违规收集使用个人信息专项治理的公告》

4.《App违法违规收集使用个人信息行为认定方法(国信办秘字[2019]191号)》

5.《工业和信息化部关于开展信息通信服务感知提升行动的通知(工信部信管函(2021]292号)》

6.《工业和信息化部关于进一步提升移动互联网应用服务能力的通知》（工信部信管函〔2023〕26号）

7.《关于开展App侵害用户权益专项整治工作的通知(工信部信管函[2019]337号)》

8.《关于开展纵深推进APP侵害用户权益专项整治行动的通知(工信部信管函[2020]164号)》

9.（2021）浙0192民初5626号

10.（2022）京0491民初1410号

11.《信息安全技术个人信息安全规范》(GBT 35273-2020)

12.《信息安全技术移动互联网应用(APP)收集个人信息基本要求》(GBT 41391-2022) 

13.《信息安全技术移动互联网应用程序(APP)个人信息安全测评规范》(GBT42582-2023)

14.《信息安全技术移动互联网应用程序(App)软件开发工具包(SDK)安全要求》(GBT43435-2023)

15.《数据安全技术敏感个人信息处理安全要求》（GB∕T 45574-2025）

16.《App违法违规收集使用个人信息自评估指南》（TC260-PG-20202A）

17.《网络安全标准实践指南一移动互联网应用程序(App)个人信息保护常见问题及处置指南》(TC260-PG-20203A )

18.《网络安全标准实践指南一移动互联网应用程序(App)收集使用个人信息自评估指南》(TC260-PG-20202A)

19.《网络安全实践指南—移动互联网应用基本业务功能必要信息规范》（TC260-PG-20191A）

20.《网络安全标准实践指南—移动互联网应用程序（App）系统权限申请使用指南》（TC260-PG-20204A）