2025年以来，数据合规执法明显加速。对大型企业而言，数据合规已经是标配。但对中小企业——很多老板的态度还是「我们又不是大厂，谁会查我们？」答案是：正在查。而且一查一个准。

2025年5月1日，《个人信息保护合规审计管理办法》正式施行；7月到12月，国家网络安全通报中心连续发布四批通报，累计点名200余款App和小程序违规收集使用个人信息。

Part 01

漏洞一：敏感个人信息的「单独同意」形同虚设

Scene 01

问题是什么

《个人信息保护法》第 29 条规定，处理敏感个人信息（生物识别、医疗健康、金融账户、行踪轨迹等）必须取得个人的单独同意。第 30 条要求，还必须告知处理敏感个人信息的必要性及对个人权益的影响。

大多数中小企业的实际做法：在隐私政策里埋了一段笼统的授权描述，用户勾选了「我已阅读并同意」就算完事。这个「一揽子同意」在法律上不足以构成处理敏感个人信息的「单独同意」。

Scene 02

监管情况

Scene 03

自查清单

• 公司是否收集人脸、指纹、声纹等生物识别信息？如有，是否在收集前弹窗取得单独同意（而非混在隐私政策里）？
• 公司是否收集员工或用户的健康数据、金融账户信息？是否有独立的授权勾选框？
• 单独同意的弹窗是否清楚告知了处理必要性和对个人权益的影响？
• 用户撤回同意是否和给出同意一样方便？（PIPL 第 15 条）

Scene 04

修补方案

1. 改造授权流程： 敏感信息收集前，设置独立的弹窗/勾选框，不得与普通个人信息混同授权
2. 告知内容三要素： （1）收集什么敏感信息 （2） 为什么必须收集（必要性）（3） 不提供会有什么后果
3. 撤回机制： 在 App 设置或小程序菜单中提供「撤回同意」入口，操作步骤不超过 3 步

Part 02

漏洞二：第三方 SDK 和外包商的「信息黑箱」

Scene 01

问题是什么

PIPL 第 17 条要求，个人信息处理者在处理个人信息前，应当告知接收方的名称、联系方式、处理目的和处理方式。第 21 条要求，委托处理个人信息的，应当与受托人约定处理目的、期限、方式及保护措施，并对受托人的处理活动进行监督。

中小企业在接入第三方 SDK（推送、统计、地图、支付等）或使用外包服务商（客服系统、CRM、数据分析等）时，最常见的问题是：自己都不知道第三方在收集什么数据。

Scene 02

监管情况

Scene 03

自查清单

• 公司 App/小程序/网站接入了哪些第三方 SDK？是否有一份完整的 SDK 清单？
• 每个 SDK 在后台收集了哪些数据？收集频率是多久一次？
• 隐私政策是否逐一列出了每个 SDK 的名称、收集信息的类型、目的和方式？
• 是否与每个数据受托处理方签署了数据处理协议？协议中是否明确了安全责任？
• 是否对受托方的数据处理活动进行过监督或审计？

Scene 04

修补方案

1. SDK 全量盘点： 技术团队导出所有接入的 SDK 清单，逐一确认数据收集范围
2. 隐私政策逐条更新： 每个 SDK 必须在隐私政策中单独一条列出——不能笼统写「我们可能接入第三方 SDK」
3. 数据处理协议签署： 与所有数据处理受托方签署书面协议，明确处理目的、期限、安全措施、违约删除义务
4. 定期审计： 每年至少一次对主要受托方进行数据安全合规检查

⚠️ 进阶合规提示：接入第三方 SDK 时需区分两种法律身份——如果双方共同决定数据处理目的和方式，构成 PIPL 第 20 条的「共同处理者」，需约定各自权利义务并承担连带责任；如果仅受托按指令处理数据，则属于 PIPL 第 21 条的「委托处理」。两者的法律责任有本质区别，建议在数据处理协议中明确约定。

Part 03

漏洞三：数据库和应用安全形同虚设

Scene 01

问题是什么

PIPL 第 51 条和《数据安全法》第 27 条要求个人信息处理者采取加密、去标识化、访问控制等必要措施保障数据安全。《网络安全法》第 21 条要求采取防范计算机病毒和网络攻击的技术措施，并留存网络日志不少于六个月。

这是中小企业被处罚最高频的漏洞。核心问题不是「没有安全措施」，而是「措施做了一半」——数据库直接暴露在公网、弱口令、明文存储、未做等级保护测评。

Scene 02

监管情况

Scene 03

自查清单

• 生产数据库和测试数据库是否都能通过公网直接访问？（答案必须是「否」）
• 数据库访问密码复杂度是否达标？是否存在默认密码或弱口令？
• 存储的个人信息（尤其是敏感个人信息）是否做了加密处理？
• 是否完成了网络安全等级保护（MLPS）定级备案和测评？
• 系统日志是否留存不少于 6 个月？
• 离职员工的数据库/系统访问权限是否及时收回？

Scene 04

修补方案

1. 公网暴露检查： 立即用安全扫描工具检查所有数据库和接口的公网暴露情况，非必要一律关闭
2. 加密存储： 对存储的敏感个人信息（身份证号、手机号、人脸数据、银行账号等）执行 AES-256 或国密 SM4 加密
3. 访问控制： 数据库访问设置 IP 白名单，启用强密码策略和双因素认证
4. 等级保护： 完成 MLPS 定级备案（中小企业通常为二级），委托有资质的测评机构完成测评
5. 日志审计： 开启并保留不少于 6 个月的网络日志和安全审计日志
6. 权限清理： 建立离职员工权限回收清单，技术、运维、客服人员离职当日即回收所有系统权限

Part 04

漏洞四：未成年人信息处理的合规空白

Scene 01

问题是什么

PIPL 第 31 条规定，处理不满十四周岁未成年人个人信息的，应当取得其父母或其他监护人的同意，并制定专门的个人信息处理规则。《未成年人网络保护条例》第 37 条要求网络游戏服务提供者对未成年人个人信息应当每年进行一次合规审计（此为法定义务，其他行业处理未成年人信息的，虽无法定年度审计要求，但参照执行属于良好的合规实践）。

大多数中小企业的做法：连自己有没有收集未成年人信息都不知道。教育、医疗、游戏、社交类企业尤其高危——但即便是电商、餐饮类企业，如果用户在注册时填写了年龄，或者通过微信授权获取了监护人关系，都可能触发未成年人保护义务。

Scene 02

监管情况

Scene 03

自查清单

• 公司的产品/服务是否可能被未成年人使用？用户注册时是否有年龄验证机制？
• 如涉及未成年人，是否制定了专门的《未成年人个人信息处理规则》？（注意：不是「在隐私政策里加一段话」，而是独立文件）
• 收集 14 岁以下未成年人信息前，是否验证并取得了监护人的同意？同意记录是否留存？
• 是否建立了监护人行使权利（查阅、复制、更正、删除）的受理渠道？
• （如为网络游戏服务提供者）是否完成了未成年人信息处理的年度合规审计？

Scene 04

修补方案

1. 年龄识别： 在注册/登录流程中加入年龄验证环节（如通过身份证号或人脸识别判断是否未成年）
2. 监护人同意机制： 对于 14 岁以下用户，设计监护人验证和授权流程（如短信验证 + 监护人身份证上传）
3. 独立处理规则： 起草并发布《未成年人个人信息保护规则》，作为独立的弹窗或文件
4. 年度审计： 网络游戏服务提供者须依法每年审计；其他行业可将未成年人信息处理合规纳入常规审计范围
5. 如不涉及未成年人： 在隐私政策中明确声明「本产品/服务不面向未成年人」，并设置年龄门槛

Part 05

漏洞五：数据出境的「无感违规」

Scene 01

问题是什么

PIPL 第 38 条规定，向境外提供个人信息的，必须通过以下三种路径之一：（1） 通过国家网信部门组织的安全评估；（2）经专业机构进行个人信息保护认证；（3）与境外接收方订立标准合同（SCC）并向省级网信部门备案。

最隐蔽的坑：很多中小企业根本没意识到自己正在「数据出境」。以下是典型无感出境场景：

• 使用海外 SaaS 工具（Salesforce、HubSpot、海外版飞书/钉钉/企业微信），员工和客户数据存储在境外服务器
• 使用海外云服务（AWS 海外区域、Google Cloud），业务数据自动同步到境外
• 通过微信/邮件将含有客户信息的 Excel 表格发送给海外母公司或合作伙伴
• App 接入了海外分析 SDK（Google Analytics、Firebase 等），用户行为数据传输至境外

Scene 02

监管情况

Scene 03

自查清单

• 公司是否使用海外服务器或海外云服务存储数据？
• 公司是否使用海外 SaaS 工具（CRM、邮件营销、客服系统等）？
• 公司是否有向境外母公司、关联公司、合作伙伴发送客户/员工信息的业务场景？
• App 是否接入了海外 SDK（数据分析、广告推送等）？
• 如以上任一答案为「是」：是否完成了数据出境安全评估申报或标准合同备案或保护认证？
• 是否在出境前完成了个人信息保护影响评估（PIA，PIPL 第 55 条）？

Scene 04

修补方案

1. 出境场景全量排查： IT、业务、法务联合梳理所有涉及数据出境的技术工具和业务流程
2. 选择合规路径： 
• 非 CIIO、处理个人信息不满 100 万人、上年累计出境不满 10 万人 → 标准合同备案（最常用）
• 达到安全评估门槛 → 向国家网信部门申报安全评估
• 跨国公司内部跨境 → 保护认证
3. 开展 PIA： 按照 PIPL 第 56 条要求，评估出境目的、方式、对个人权益的影响、境外接收方的保护水平等，报告保存至少三年
4. 技术替代： 能切换到中国境内服务器的 SaaS 工具，优先切换（如用国内版飞书替代海外版）
5. 员工数据出境： 如涉及员工信息出境（跨国公司的常见场景），制定《员工个人信息出境处理规则》并取得单独同意

Part 06

附一：合规审计——2025 年以后的新标配

国家网信办已发布《个人信息保护合规审计管理办法》，确立了分层审计框架。以下为征求意见稿中的核心要点（最终正式稿可能有所调整）：

关键提醒：中小企业的审计义务并不因「无法定强制频次」而免除——PIPL 第 54 条要求所有处理者「定期」进行合规审计。没有做过一次审计，本身就是不合规的证据。

Part 07

附二：一条被忽视的先行义务——PIA（个人信息保护影响评估）

在修补前文五个漏洞的过程中，有一项法定前置义务经常被遗漏：个人信息保护影响评估（PIA）。

PIPL 第 55 条明确规定，在以下场景中，必须事前进行 PIA：

• 处理敏感个人信息（对应漏洞一）
• 利用个人信息进行自动化决策
• 委托处理个人信息（对应漏洞二中的合作方信息黑箱问题）
• 向境外提供个人信息（对应漏洞五）

这意味着：你在修补漏洞的同时，应当同步完成并留存 PIA 记录。PIA 报告需涵盖处理目的、方式、对个人权益的影响和安全风险、保护措施的有效性，且保存至少三年（PIPL 第 56 条）。这是向监管证明「已尽到合规义务」的关键书面证据——没有 PIA 记录，前面的修补工作相当于「有行动没留痕」。

实操建议：建议在启动任何一项漏洞修补工作时，同步建立一份 PIA 台账（Excel 即可），按场景逐一记录评估结论。待到《个人信息保护合规审计管理办法》正式施行后，这份台账将成为审计时的第一手材料。

Part 08

五漏洞速查表

Part 09

写在最后

数据合规正在从「大厂专属」走向「全行业标配」。2025 年以来四批通报、三部门联合专项行动、审计办法落地——每一个信号都在指向同一个趋势：不因为你规模小就不查你，恰恰因为你规模小、合规意识弱，才最容易成为典型案例。

本文梳理的五个漏洞，每个都可以在一周到一个月内启动修补。建议今天就做三件事：

1. 把这份清单发给技术负责人，逐条排查
2. 让法务或外部律师起草或审查一版隐私政策和数据处理协议
3. 在下一次管理层会议上，把数据合规列入正式议程——而不是「等出了问题再说」

数据合规，不怕开始得晚，就怕从来没开始。

Part 10

📚 参考文献

文章内容如涉及作品内容、版权和其它问题，请在30日内与本公众号联系，我们将在第一时间删除内容。文章只提供参考并不构成任何投资及应用建议。

欢迎交流

如果您对数据合规有任何疑问，欢迎留言或私信交流。

关注公众号