违规收集个人信息：哪些做法算违规、怎么判断「过度」、被通报后怎么办

一句话定义：违规收集个人信息是指个人信息处理者在收集环节违反合法、正当、必要、诚信原则，或者未依法告知、未取得有效同意的行为。它不是「收集之后出了事」才成立，而是收集行为本身违法即成立。核心依据是个人信息保护法第五条、第六条、第十三条、第十六条、第十七条，以及网络安全法第四十三条与消费者权益保护法第二十九条。

本词条属于网络与数据栏目。关于违规收集，实务中有三个高频误判：以为「用户点了同意就不算违规」；以为「不同意就不给用是行业惯例，没人管」；以为「只是收集、没有泄露，所以没风险」。三个误判分别错在把「同意」当成了唯一的判断标准、把「普遍做法」当成了「合法做法」、把「违规收集」当成了必须以泄露为前提。

构成要件

一、五道关，缺一不可。 判断一次收集行为是否合规，要依次过五道：目的正当（第五条，合法、正当、必要、诚信，不得通过误导、欺诈、胁迫等方式处理）；最小必要（第六条，与处理目的直接相关、影响最小、限于最小范围）；告知充分（第十七条，四项法定事项）；同意有效（第十四条，充分知情、自愿、明确）；后续合规（第五十一条，制度、分类管理、加密去标识化、权限控制、应急预案）。五道关是并列关系，任何一道不过，收集行为就不合规。

二、「必要」的判断标准是「与提供的服务直接相关」，不是「对业务有用」。 第六条要求处理目的明确、合理、与处理目的直接相关，采取对个人权益影响最小的方式，收集限于实现处理目的的最小范围。中华人民共和国网络安全法第四十三条第二款说得更直白：网络运营者不得收集与其提供的服务无关的个人信息。

这里的关键是「功能相关性」，不是「商业价值」。手电筒应用要通讯录、计算器要精确位置、壁纸应用要短信权限——这些不是「有用」，而是「无关」。商业上有用、技术上方便，都不能把「无关」变成「相关」。

判断可以走三步：其一，这个功能没有这项信息能不能实现？（不能实现才叫必需）其二，有没有侵入性更小的替代方式？（用模糊位置代替精确位置、用相册选择代替全盘读取）其三，收集的频率与范围有没有超出功能需要？（使用时定位与后台持续定位，是两件不同的事）

三、「不同意就不给用」是明文禁止的，例外很窄。 个人信息保护法（全文见中华人民共和国个人信息保护法）第十六条规定：处理者不得以个人不同意处理其个人信息或者撤回同意为由，拒绝提供产品或者服务；处理个人信息属于提供产品或者服务所必需的除外。

「所必需」与前面说的「必要」是同一个标准：地图导航要位置，是必需；短视频要通讯录，不是必需。所以正确的产品设计是「分功能授权」——不给通讯录，仍然能看视频；不给位置，仍然能浏览内容，只是不能用导航功能。这一条是应用被通报的最常见原因：把非必需权限做成了强制项，用户不点同意就停在启动页。

四、告知要「显著、清晰易懂、真实、准确、完整」。 第十七条列了四项必须告知的内容：处理者的名称与联系方式；处理目的、处理方式、处理的个人信息种类、保存期限；个人行使权利的方式和程序；法律、行政法规规定应当告知的其他事项。事项变更的，还要就变更部分告知。

常见的告知瑕疵有五种：隐私政策藏在三级页面、进入路径要点击四五次；用极小字体或者低对比度排版；用「可能收集您的一些信息」这种模糊表述；把关键条款放在附件或者外链里；版本更新后不重新告知。「真实、准确、完整」三个词各有独立含义：真实是不能虚假陈述（说「不收集位置」却在收集）；准确是不能含糊其辞；完整是不能遗漏法定事项，尤其是第三方共享、保存期限、行使权利的方式这三项最常被漏。

五、嵌入的第三方组件，责任在应用运营者。 应用里集成的推送、统计、广告、地图、支付组件，它们收集的信息在监管口径上视为应用运营者收集的信息。「这是组件自己收集的、我们不知情」不是抗辩——你选择了这个组件、把它打包进了自己的产品，就要对它负责。

实务上的四项要求：接入前审查组件的收集清单与权限申请；在隐私政策中逐项列明第三方组件的名称、收集的信息类型、使用目的；在应用内提供关闭或者退出通道；定期复核组件版本，旧版本组件常在后台静默采集，是通报的高发点。

六、「默认勾选」与「捆绑授权」不是有效同意。 第十四条要求同意是「充分知情、自愿、明确」作出的。默认勾选：用户没有任何主动动作，不构成「明确」；捆绑授权：把多项处理目的打包成一个「同意」按钮，用户无法分别选择，不符合「充分知情」；频繁索权：用户已经拒绝仍反复弹窗，构成骚扰，也可能被认定为变相强制。

正确的做法是三条：分项同意（不同目的分别征求）；单独同意（处理敏感个人信息、向他人提供、公开披露、跨境提供等情形要单独取得）；拒绝后不再反复弹窗，并提供便捷的撤回路径——撤回的便捷程度要以授权时的路径为比较基准，不能「一键授权、十步撤回」。

七、违规收集不以「造成泄露」为前提。 这一点最容易被误判。违反第五条、第六条、第十三条、第十七条，本身就是独立的违法事由，监管可以直接责令改正、给予警告、没收违法所得、处以罚款，不需要证明发生了泄露，也不需要证明用户受到了实际损失。

罚则按第六十六条：一般违法，责令改正、警告、没收违法所得，对违法处理的应用程序责令暂停或者终止提供服务，拒不改正的并处一百万元以下罚款，对直接负责的主管人员和其他直接责任人员处一万元以上十万元以下；情节严重的，由省级以上部门责令改正、没收违法所得，并处五千万元以下或者上一年度营业额百分之五以下罚款，可以责令暂停相关业务或者停业整顿、通报有关主管部门吊销许可或者执照，对个人处十万元以上一百万元以下罚款，并可以决定禁止其在一定期限内担任相关企业的董事、监事、高级管理人员和个人信息保护负责人。

「情节严重」的常见考量因素：处理的是敏感个人信息；涉及人数巨大；违法行为持续时间长；经责令改正仍不改正；造成严重后果或者恶劣社会影响；侵害未成年人权益。这几项里，「持续时间长」和「经责令不改」是监管最容易取证的，也最容易被用来抬档。

八、未成年人信息是加重情节。 不满十四周岁未成年人的个人信息属于敏感个人信息，处理应当取得父母或者其他监护人的同意，并制定专门的处理规则。「我们不知道用户是未成年人」通常不能免责——面向未成年人的产品、有明显未成年人使用特征的产品（校园场景、儿童内容、青少年模式），应当主动采取年龄识别或者默认保护措施。关于敏感个人信息的完整规则，可对照敏感个人信息那一篇。

九、被通报后的处置有固定套路，顺序不能乱。 监管通报之后的标准动作是：先下架或者停止相关功能 → 逐项对照通报问题自查 → 完成整改并留存证据 → 提交整改报告 → 接受复测 → 恢复上架。

四个实务要点：其一，通报问题往往只是抽样，要自查同批次、同类型、同组件的其他问题，只改被点名的那一项，下一轮很可能被点更多；其二，整改报告要写清「问题→原因→措施→验证方式」四段，只写「已整改」通常会被退回；其三，同一问题二次被通报，处罚会明显加重，可能从责令改正直接跳到罚款；其四，整改期间不要偷偷恢复上架，会被认定为拒不改正，直接落入「情节严重」。

十、民事与行政并行，民事举证对用户有利。 第六十九条规定，处理个人信息侵害个人信息权益造成损害，处理者不能证明自己没有过错的，应当承担损害赔偿等侵权责任。用户只需要证明「我是用户」「发生了侵害」「我受损」，过错由处理者自证。

但要注意一个现实：单个用户的实际损失通常很小，真正的威胁来自集体维权与公益诉讼——消费者组织、检察机关可以就侵害众多消费者权益的行为提起公益诉讼。这也是为什么企业应对违规收集，不能只算「被罚多少钱」，还要算「潜在的群体性索赔」。

法条依据

与相邻概念的区别

一、与个人信息泄露的区别。 泄露是保管环节出了问题，违规收集是入口环节本身不合法。两者是独立的违法事由——即使一次泄露都没发生，收集行为违规照样被罚；反过来，收集合规也不能免除泄露时的责任。实务上经常被混在一起谈，导致企业以为「没泄露就没事」。

二、与大数据杀熟的区别。 违规收集是入口，差别定价是出口。没有违规收集，杀熟往往做不出来——要做用户画像、要识别支付能力，就得先收集相应信息。但两者的违法构成完全不同：前者看收集行为本身，后者看定价的合理性与差别待遇有没有正当理由。

三、与骚扰电话、垃圾短信的区别。 后者发生在使用与对外提供环节，归消费者权益保护法第二十九条第三款、通信管理相关规定管；前者发生在收集环节。同一款应用可能同时踩两条线：过度收集通讯录＋向第三方提供号码用于营销。

四、与网络安全等级保护的区别。 等保管的是系统本身的安全（定级、备案、测评、日志留存）；违规收集管的是处理行为是否合法。过了等保测评，不等于收集行为合规——这是两套完全不同的评价体系，很多企业把等保当成「个人信息合规的证明」，是明显的误解。

实操指引

第一步，做一张「功能→信息」对照表。 左边列产品功能，右边列该功能真正必需的信息，中间写「没有这项信息这个功能能不能实现」。这张表是应对检查最有效的材料，因为它直接回应了「必要性」这个问题。做表时要注意：一项信息如果只对「提升推荐效果」有用、对功能实现没用，就不属于必需。

第二步，把权限申请改成「分功能、按需、可拒绝」。 用户进入某个功能时才申请对应权限；拒绝后功能降级但不阻断整体使用；拒绝后不再反复弹窗；设置页提供统一的权限管理入口。这四条做到，第十六条与「频繁索权」的问题基本可以解决。

第三步，重写隐私政策，按「看得懂」的标准。 结构建议：收集哪些信息（分类列）、每一项用来做什么、保存多久、提供给谁（列明第三方组件与共享对象）、用户有什么权利、怎么行使、怎么联系。写完做一次可读性测试：找一个非技术、非法律的同事读一遍，问他三个问题——收集了什么、用来干什么、不想要怎么办。三个问题答不上来，就说明还得改。

第四步，把第三方组件清点一遍。 列出所有组件的名称、版本、收集的信息、申请的权限、是否可关闭。重点核查三类：推送类、统计类、广告类——这三类最容易在后台静默采集。清点结果要同步到隐私政策，并对旧版本组件做升级或者替换。

第五步，建立同意与撤回的记录机制。 谁能证明「用户同意过」？要有可追溯的记录：同意时间、同意方式、同意时的政策版本、同意范围。撤回同样要留痕，并且撤回后要在合理时间内停止相应处理。这套记录在监管检查与民事抗辩中都是关键证据。

第六步，把整改做成可复用的流程。 建立「自查清单→整改台账→复核→留档」的闭环，每次版本发布前跑一遍清单。这套流程同时也是合规体检的核心内容，可以参照企业合规体检全流程的思路搭建。 个人一侧如果认为自己的信息被违规收集，可以先看网络个人信息的常见问题，也可以先用个人信息保护维权判定器做一次初步判断，需要正式主张权利的，文书可以参考个人信息侵权投诉函。

常见问题