个人信息保护合规审计系列总结篇（一）

引言：本系列推文已经沿数据生命周期全流程，完整拆解了各环节对应的审计审查要点。进入总结篇，我们将精选实务中合规难度最高的环节，为企业明确合规落地的具体标准与验证方式。本篇将重点聚焦收集和委托处理环节的要点。

一、收集环节——最小必要原则

最小必要原则是《个人信息保护法》第六条确立的核心原则，也是个保审计在收集环节审查密度最高的节点。在此前推文中，我们已概述了这一原则的基本要求，即“收集个人信息的范围应当限于实现处理目的的最小范围，不得过度收集”。当这一原则从制度文本进入审计实务，审查的落点随即聚焦为以下三个具体问题：

（一）权限申请的时机与频次

实务中对最小必要原则的审查，不只看“申请了什么权限”，更看“什么时候申请”和“申请了多少次”。常见的错误做法是：App在用户首次打开时一次性弹出一连串的权限申请，而用户尚未触发其中多项权限所对应的功能。2026年中央网信办、工信部、公安部联合发布《关于开展2026年个人信息保护系列专项行动的公告》，将“在无关场景收集位置、通讯录、短信等个人信息，超出最低必要频率调用个人信息权限”列入重点治理。

由此可见，审计审查关注两个重点：权限申请的时机是否与用户即将使用的具体功能形成即时关联，以及权限调用的频次是否与业务目的形成合比例关系。例如，导航功能持续定位需要高频调用位置信息，而天气更新仅需低频获取粗略位置，两者在必要性上的论证程度截然不同。审查要求企业就每一次权限调用的具体业务目的和频率依据分别提供说明，而非以“提供基于位置的服务”笼统概括。

（二）SDK的静默采集与连带责任

2026年三部门专项行动公告将“嵌入的SDK个人信息收集使用活动”单独列为治理对象，明确了App开发者对所嵌入的第三方SDK承担合规监督义务，不得以“SDK由第三方提供”为由免除自身责任。这意味着审计时极有可能核验每一款SDK在初始化、运行及后台状态下实际触发的数据采集行为，而非仅审查SDK提供方出具的权限声明文件。

进一步分析审查逻辑，公告禁止的是“超范围采集”这一结果，而非某一种特定的采集方式。这意味着，企业必须证明自己没有触碰这条红线。为此，我们为企业准备了三个递进问题：首先，SDK实际采集了哪些信息；其次，采集行为是否发生在用户同意之后；最后，如果用户拒绝了某项权限，SDK是否还通过其他路径获取了功能等同的信息？只有三个问题的答案都有据可查，才能够符合合规举证要求。

（三）业务必要性举证

2025年8月，最高人民法院发布数据权益司法保护专题指导性案例，其确立了判断“履行合同所必需”的核心标准：缺乏该信息是否会导致合同基本功能无法实现；若仅为实现增值服务，则不属于必需。该案例裁判要点进一步阐明：不能以“改善服务质量”“提升用户体验”“优化推荐算法”等概括性理由将增值服务纳入必需范畴。

综上，这一裁判规则在审计中被转化为一项明确的论证义务：企业若主张某项超出核心功能的数据收集是“必需”的，不能以优化服务、提升体验等宽泛说法一笔带过，而必须正面回应三个层层递进的问题。第一，缺少这项信息，合同的哪项核心功能会彻底无法实现？第二，这项信息与核心功能的实现之间，是否存在不可替代的因果关系？第三，为什么用更少的数据类型或更低的频率，就无法达到同样的功能要求？这三项论证均须形成书面记录，且每一项都必须成立。

二、委托处理——持续监督

委托处理是此前第六篇推文的核心议题之一。本篇在前文基础上进一步细化三个实务中容易被忽略的节点：监督频率的确定方法、分包穿透的合规操作，以及合作终止后的数据处置验证。

（一）监督频率

在此前的推文中我们已经提到过，现行法规未直接规定委托方对受托方的具体监督频率。然而法规虽然没有明确规定数字，但规定了“定期”和“必要”两个判断维度。企业需要将这两个维度转化为内部制度中可执行的监督频率确定方法，而非笼统地都采取同一个标准以应对监管。

《个人信息保护合规审计管理办法》第4条对处理者自身整体审计频次规定如下：处理超过1000万人个人信息者每两年至少一次，处理超过100万不超过1000万人者每三年或四年一次。这可以为理解“定期”的立法思路提供参照，但企业不应将这一频次直接套用到对第三方的监督上。监督频率的确定应当额外考量以下因素：受托方处理的数据类型和敏感程度，受托方是否曾发生数据安全事件，受托方在合同期内的合规表现，受托方所在国家或地区的数据保护法律环境，以及数据处理活动的规模和复杂程度。审计审查的重点不在于企业设定了一个什么频率，而在于这个频率的确定是否有合理的论证过程、是否形成书面记录，以及企业是否按照内部制度规定的频率实际执行了监督。

而在“必要”这个维度解决的是企业监督的充分性问题，对应审计审查就是围绕三个递进层面展开。第一个层面是监督方式的差异化匹配：处理敏感个人信息或大规模数据的受托方，企业仅仅采用远程问卷式的审查不足以满足充分监督的要求，现场检查或独立第三方审计才是与风险等级相匹配的合理监督手段。第二个层面是触发式监督机制的建立：受托方发生数据安全事件、被监管通报、控制权或核心人员变动、所在国数据保护法律环境发生重大变化时，企业是否主动启动专项监督而非被动等待下一个定期节点。第三个层面是问题处置的闭环管理：发现问题、要求整改、整改回复、验证确认四个节点缺一不可。“必要”这一要素的满足关键就在于企业在正确的时间采取正确的处置。

（二）分包穿透

云服务商的数据存储分包给次级服务商，是实务中普遍存在但合规管理常常未能穿透的情形。如果委托处理合同中没有明确限制或约定分包条款，受托方可能在委托方不知情的情况下将部分处理活动转委托给次级服务商，导致委托方的数据流向出现监管盲区。

《个人信息保护法》第二十一条规定，受托方转委托应当事先征得委托方同意。这一“同意”不是泛泛的概括授权，而应当针对具体的次级服务商和具体的处理活动逐次取得。审计审查重点在于：企业签订的委托处理合同是否明确了转委托的禁止或限制条款；如果允许分包，是否建立了分包审批机制；委托方是否对次级服务商进行了与主受托方同等的安全资质审查；次级服务商的清单和资质审查记录是否留存完整；委托合同终止时，是否对次级服务商同步执行了数据删除或返还的要求。分包穿透的核心，是将合规管控从一级受托方逐层延伸至整条委托链条的末端，每一层都适用相同的审查标准与监督要求。

（三）合作终止后的数据处置验证

委托关系终止后，受托方是否完成了数据删除，是委托处理全周期管理的最后一个节点，也是最容易被忽视的节点。实务中，企业更换云服务商或终止外包合作时，关注重心集中在业务迁移和数据导出，而旧服务商是否真的删除了全部数据，往往无人追踪。仅凭受托方书面承诺“已完成数据删除”，不足以证明处置义务的履行。

审计审查要求这一环节形成完整的验证闭环。委托方应当在委托处理合同中事先约定终止后数据处置的具体方式、时间节点和证明要求。在合作终止时，委托方应当取得受托方出具的数据删除确认函，确认函中应当明确载明删除的数据类型、删除方式、完成时间，并由受托方正式签章。对于高风险的数据委托处理场景，委托方还应当通过技术手段对删除结果进行抽样验证。这些验证记录，与委托合同中的终止条款、受托方的删除确认函共同构成完整的处置证据闭环。