个人信息保护合规审计——真正的个人信息删除：技术与业务的平衡

‍‍‍‍

2024

上文中我们从公司内部数据删除落地和合规审计——两个角度做了初步讨论。陆续有读者私信或者留言提出更具体的问题，比如什么是真正的删除？逻辑删除算不算？技术上有困难或者业务不让删除如何处理？本文继续抛砖引玉，讨论合规删除的定义，以及各种问题和挑战的潜在解决方案。

《个人信息保护法》第47条规定，有下列情形之一的，个人信息处理者应当主动删除个人信息；个人信息处理者未删除的，个人有权请求删除：

（一）处理目的已实现、无法实现或者为实现处理目的不再必要；

（二）个人信息处理者停止提供产品或者服务，或者保存期限已届满；

（三）个人撤回同意；

（四）个人信息处理者违反法律、行政法规或者违反约定处理个人信息；

（五）法律、行政法规规定的其他情形。

法律、行政法规规定的保存期限未届满，或者删除个人信息从技术上难以实现的，个人信息处理者应当停止除存储和采取必要的安全保护措施之外的处理。

个人信息删除是个人信息处理生命周期的重要环节，也是个人信息保护的核心环节之一。当企业依据《个人信息保护法》规定落实数据删除以履行法定义务以及应对合规审计时，首先是明确数据删除的时间，是删除还是保留？如何确定期限？这个之前我们也有讨论（）。本文主要关注删除技术落地，什么删除效果是合规的，其中一些困难如何解决，技术上难以实现如何理解。

一、真正的个人信息删除是什么？

在满足其他法律法规或其他合法理由保留要求前提下删除个人信息，从法律、技术两个层面来看：

1. 法律层面

《个人信息保护法》并没有直接说明数据删除在技术上达到什么效果才是合规的删除。但是从个人信息的定义来看，如果个人信息经过技术处理，彻底删除而无法恢复，或者处理结果不能认定为个人信息，即达到匿名化效果，则是真正的数据删除。

《个人信息保护法》第四条：个人信息是以电子或者其他方式记录的与已识别或者可识别的自然人有关的各种信息，不包括匿名化处理后的信息。

2. 技术层面：

数据被彻底清除，包括主数据库、副本、缓存和日志等位置。
数据不可恢复，即便使用专业的恢复工具也无法还原。
涉及硬件的情况（例如存储介质），需要确保物理销毁或数据擦除。

二、技术上难以实现如何理解？

《个人信息保护法》第47条第二款提到，删除个人信息从技术上难以实现的情况，个人信息处理者应当停止除存储和采取必要的安全保护措施之外的处理。换句话说，如果技术上无法删除，则应该安全地保存好个人信息，不能做其他的数据处理。

显然立法者也意识到了删除的技术困难。但技术上难以实现如何理解呢？什么样删除难度可以豁免删除义务？这更多是一个技术问题，而不是法律问题。笔者认为，这需要专业技术人员判断：技术难度是否超出当前技术能力：是否因现有技术限制而无法删除数据。企业如果确定存在技术困难而无法删除，则建议将判断过程或者专业鉴定记录在案，以备诉讼或者审计之用。

另外除了技术上的困难，笔者提问：成本和业务影响是否也是法定考量因素，毕竟也是现实存在的问题：

成本是否显著高于合理范围：删除行为是否需要耗费过高的资源或成本（如需要完全重建备份系统）。
删除行为是否会造成系统或服务不可用：删除操作是否会对正常业务运作造成重大影响。

三、在实际业务中有哪些困难？

如前所述，技术、成本和业务因素都是数据删除落地路上的挑战。以下列举一二：

1. 技术层面的挑战

（1）数据存储的分散性

数据往往分布在多个系统、平台、和地理位置：

数据库：可能存在多个副本（主从库、缓存）或分布式存储（如HDFS）。
备份：定期数据备份的设计可能导致数据即使删除了原始存储仍然存在。
云存储：不同供应商的存储策略可能导致删除操作复杂化。

（2）数据依赖性与关联性

数据之间可能存在复杂的依赖关系：

外键关联：删除某条数据可能会影响其他数据记录。
业务逻辑依赖：例如订单、发票、日志等可能依赖用户信息，直接删除会破坏业务流程。
关联数据的隐性依赖：例如推荐系统训练模型可能保留了用户行为数据的结果，需判断这些结果是否也需要删除。

（3）数据冗余和复制

数据在处理过程中可能会产生多个冗余副本：

临时文件：一些临时存储的数据可能未被清理。
日志记录：系统日志中可能包含用户数据。
缓存：例如CDN缓存或应用内的内存缓存可能继续保存被标记为删除的数据。

（4）备份数据的删除

数据在备份系统中可能被多次复制，而备份策略通常设计为只追加不删除，这导致删除备份中的特定用户数据变得困难。
删除备份中的单条数据可能破坏备份完整性，因此需要等待备份过期自动清理。

2. 合规和业务需求：

（1）保留要求：为了合规（如税务、合同保留期限）或防止法律争议，法务和业务部门往往都有保留数据的诉求，这都属于正当合理需求，但如何把不同法律要求删除时间逻辑落地并非易事。

（2）用户体验和反欺诈需求：为了防止用户删除后反悔，部分平台可能“伪删除”，如软删除（标记为删除，但未实际清除）。同时也防止会员注销后，注册新用户反复薅羊毛。

（3）业务阻力：众所周知，数据是资产，业务团队不愿删除，如会员信息、交易数据等。对于数据价值的期待，尤其在不清楚数据价值但预期很高，同时不了解保留风险的情况下，选择不删除。

3. 管理和流程上的挑战

（1）删除请求的验证

如何验证用户的删除请求是合法且确实由本人发起：身份验证：确认发起请求的用户是否为账户的所有者。
避免误删除：需要多次确认或审批流程。

（2）审计与记录

删除操作本身需要保留记录以支持审计：如何证明删除了用户数据但又不泄露用户隐私。
在满足审计需求的同时避免记录中残留用户敏感信息。

（3）多部门协作

数据删除通常涉及多个部门，多部门协作可能导致流程复杂化或延迟：

IT部门执行删除操作。
合规和法务部门确认删除的合法性。
业务部门评估删除对业务流程的影响。

（4）员工意识与操作错误

员工对数据删除的重要性和合规要求理解不足可能导致：数据误删除。
删除后未及时更新状态，导致用户再次请求删除时出错。

（5）成本和资源消耗：

删除操作的成本（包括技术开发、数据迁移和系统升级）高昂，尤其是技术债较多的情况下。
高频删除申请可能对企业基础设施造成额外压力。

四、如何应对这些挑战？

以上每个挑战都有其解决方案，重要的是平衡合规与业务需求。由于篇幅有限，下面从不同视角给出框架性的解决方案，以供参考：

1.法律与合规视角

设定明确的保留期：根据法律和业务需要制定合理的数据保留和删除政策。
透明化：在隐私声明中清晰说明个人信息如何被存储和删除。当然也要给自己留足合理的操作余地。

2.技术实现视角

数据治理：重视数据治理建设，通过数据资产识别和登记，构建统一的数据地图，了解数据在整个系统中的流转与存储位置。
数据打标和分类：通过数据分级和生命周期管理，明确需要删除的数据。引入自动化规则，定期检测和删除超期数据。
统一存储与日志管理：减少分散存储，便于集中管理和验证。开发或者采购自动化的删除工具或者服务，确保主系统与副本、日志的同步删除。
软删除与硬删除结合：短期内可通过软删除（标记删除），长期内执行硬删除（彻底清除）。
删除有效性测试：定期测试删除功能，评估技术实现的有效性。

3.业务协同视角

协同业务策略：负责数据合规人员不仅要解释合规需要，也要提供合规解决方案。换句话说，不仅要告诉业务法律要求是什么，而且还需要告诉业务如何做，最好最小化减少对业务的影响。这不仅是商业本质的要求，也是向前一步跨越知识鸿沟的必然路径。例如，业务不想在用户注销账号后删除身份信息，担心用户重复注册薅羊毛。在没有删除技术障碍的情况下，可以提议业务设计新会员权益的技术防作弊机制，如仅保留绑定手机号或身份证哈希值，删除原始数据。再举一个例子，某社交媒体平台用户要求删除数据，但业务部门担心删除内容会破坏平台的用户体验（如删除评论导致评论链不完整）。可能的解决方案是通过脱敏显示与匿名处理需要删除的用户名和评论内容，或者分离个人信息与非个人信息（如评论内容与用户名分离），仅删除关联的个人信息。