企业应用中的数据保留政策与客户数据删除

大多数企业都勤于收集数据，却很少考虑何时该放手。客户数据库不断膨胀，日志堆积多年，旧备份从不删除，导出的文件散落在共享文件夹里。无理由保存的数据越多，风险面就越大：涉及更多人的泄露、不必要的存储成本，以及越来越难以履行的法律义务。

数据保留政策回答一个简单的问题：每一类数据保存多久、为什么保存，以及到期之后怎么办。本文介绍如何为企业应用制定这份政策，包括如何应对客户的删除请求、管理备份与日志，并在系统中实施而不破坏报表和账务义务。

摘要

• 数据保留是规定每类数据保存多久、如何销毁或匿名化的规则
• 制定依据：法律与税务义务、运营需要以及数据最小化原则
• 不同数据的保留期不同，没有一个适用于所有数据的数字
• 客户删除请求需要清晰的流程和有文档记录的例外
• 备份、日志和其他系统中的副本常被遗漏，必须纳入政策
• 将删除自动化；只写在文档里的政策很少被执行

为什么数据保留很重要

除合规之外，还有三个商业理由。

• 降低风险：不存在的数据不会泄露。发生安全事件时，受影响记录的数量决定损失规模和通知义务。应对计划见[网络安全事件响应计划](/blog/rencana-respons-insiden-keamanan-siber-untuk-bisnis)
• 降低成本：存储、备份和索引旧数据会推高云账单并拖慢系统。参见[数据库变慢的问题](/blog/performa-database-dan-aplikasi-bisnis-yang-melambat)和[控制云成本](/blog/mengendalikan-biaya-cloud-untuk-bisnis)
• 提升质量：过时的数据，如旧电话号码和已搬迁的地址，会降低营销活动和报表的质量，参见[数据质量与数据治理](/blog/kualitas-data-dan-tata-kelola-data-untuk-bisnis-menengah)

从法律角度看，印尼《个人数据保护法》要求数据控制者仅在处理目的所需的期间内保存数据，并在目的达成或数据主体按规定提出请求时删除或销毁。另一方面，法规要求某些文件，尤其是账簿和税务文件，必须保存规定年限。这两项要求并不冲突，但需要按数据类型逐一对应。合规基础请阅读网站与应用的个人数据保护。本文不构成法律建议；适用于您行业的保存期限请向法律顾问或税务顾问确认。

第 1 步：盘点数据

你无法为自己不知道的数据设定保留期。先列一份清单：

• 收集了哪些数据（姓名、联系方式、地址、交易记录、照片、身份文件、位置、录音）
• 数据从哪里来（表单、收银、应用、集成、购买的名单）
• 存放在哪里：主数据库、电子表格、邮件、即时通讯应用、云存储、员工笔记本
• 谁有访问权限
• 用于什么目的
• 与哪些方共享（支付处理商、快递、营销工具）

这份清单也是一份如实的隐私政策的基础。许多企业会惊讶地发现客户数据的副本出现在意想不到的地方，例如多年前下载的报表导出文件。

第 2 步：分组并设定保留期

按数据性质和保存依据分组，再为每组设定期限。

交易与财务数据

发票、付款凭证和账务记录通常依税法和会计规则必须保存多年。即使客户要求删除，这一点同样适用；解决办法是限制使用，而不是删除。电子文件的背景见ERP 的电子发票与税务合规，归档见ERP 文档管理与数字档案。

客户与账户数据

资料、联系方式、偏好。依据是仍在持续的关系。可设定规则，例如“24 个月无活动的账户先发出提醒，30 天内无回应则匿名化或删除”。

营销数据

潜在客户名单、活动结果和订阅同意。在一段时间内从未回应的名单应当清理。保存同意与退订记录的时间以能证明合规为限，参见电子邮件营销与自动化。

员工与应聘者数据

在职员工档案保存至任期结束，再加上劳动与税务规定要求的期限。未被录用的应聘者数据应在合理期限后删除，或仅在获得许可时才保存更久。参见保护员工个人数据和招聘与应聘者跟踪系统。

日志与技术数据

访问日志、错误日志和审计轨迹。技术性错误日志可以保存较短时间，例如 30 到 90 天。内部控制的审计轨迹通常保存更久，参见ERP 的审计轨迹与内部控制。确保日志不包含不必要的个人数据，如密码或卡号。

录音与沟通记录

客服通话录音、聊天记录和工单。仅在对服务质量或争议有用的期间内保存。AI 语音代理产生的录音需要特别关注，参见客户服务的 AI 语音代理。

第 3 步：确定期满后的处理方式

删除不一定意味着彻底丢弃。有几种选择。

• 永久删除：记录从系统中消失，并随时间从备份中消失
• 匿名化：去除身份信息，但汇总数据仍可用于分析，例如不含买家姓名的各产品销量
• 假名化：用代码替代身份，映射密钥单独保存并受限访问
• 受限归档：数据迁入冷存储，仅在法律需要时打开
• 使用锁定：必须保留的数据继续存在，但被标记为不得用于营销

正确的匿名化不仅仅是删掉姓名。出生日期、邮编和交易记录的组合往往仍能识别出某个人。请测试匿名化后的数据能否被重新关联到特定的人。

处理客户的删除请求

客户在特定条件下有权要求删除其数据。请准备一个不依赖某个人记忆的流程。

建议流程

• 通过官方渠道接收请求，例如表单或专用邮箱，并记录收到日期
• 核实请求人身份，避免数据被删除或交给错误的人
• 根据盘点清单找出请求人数据的所有位置
• 确定哪些数据因法律义务必须保留，并向请求人说明理由
• 删除或匿名化其余数据，包括第三方处理方系统中的数据
• 记录所采取的行动，并在合理时间内向请求人确认

合理的例外

账务数据、正在进行的争议和报告义务可以成为拒绝部分删除的理由。请记录理由。无解释地拒绝会引发投诉。

为什么要从一开始就设计

在并非为此设计的数据库中删除一位客户很困难：旧订单、发票和报表都引用客户数据。请将表结构设计为身份数据与交易数据分离，这样可以匿名化身份而不破坏销售数字。ERP 主数据的原则对此有帮助。

备份、日志与隐藏的副本

保留政策常常在没人看到的地方失效。

备份

如果你从数据库中删除了某位客户，但每日备份保存两年，数据依然存在。通常可接受的做法是：让备份按正常周期过期，并且绝不把已删除的数据恢复到生产环境。如果某天恢复了备份，请重新执行删除清单。另外保留一份不含个人数据本身的删除记录。备份细节见企业数据备份策略和灾难恢复计划。

测试与开发环境

开发者笔记本或测试服务器上的生产数据库副本常被遗忘。开发时请使用合成数据或脱敏数据。

第三方工具

客户数据可能存在于营销工具、客服系统、分析工具和支付服务商中。确保与它们的合同涵盖删除，并且你知道如何触发。这一数据供应链层面与系统间的实时集成相呼应。

导出文件与邮件附件

通过邮件发送的含客户数据的电子表格会失控扩散。限制导出，为共享链接设置有效期，并培训团队删除临时文件。

系统中的技术实现

日期与状态列

添加标记，如最近活动日期、保留依据和保留到期日。没有这些标记，删除任务就找不到已过期的数据。

定时任务

创建定期任务，查找超出保留期的记录并进行处理：标记、提醒，然后删除或匿名化。这类工作适合定时函数，参见无服务器与边缘计算中的讨论。

软删除与硬删除

软删除（将记录标记为已删除）有助于从错误中恢复，但不满足删除义务。请在软删除后设置时限，然后执行硬删除。

删除审计轨迹

记录删除已发生、何时、依据哪项政策、由哪个流程执行，而不再保存被删除的数据。这是你合规的证明。

测试

在开发环境中测试删除：确保报表保持一致、关联不会断裂，匿名化的客户出现在旧数据中时不会出错。迁移与表结构变更的测试见无停机数据库迁移。

治理与习惯

• 指定政策负责人，可以是运营负责人或数据保护官
• 每年或有新系统时复审政策
• 选择供应商和构建新功能时把数据保留纳入检查清单；参见[解读软件公司的方案书](/blog/membaca-proposal-software-house)和[软件开发合同要点](/blog/poin-penting-kontrak-pengembangan-software)
• 培训团队：哪些可以下载，在个人设备上可保存多久
• 用非技术人员能理解的语言记录所有内容

一个简单的保留表示例

以下仅用于说明如何组织，并不是适用于所有企业的数字。请根据所在行业的法规调整。

• 发票与账务文件：依税务与会计规定，并锁定不得用于营销
• 活跃客户资料：关系存续期间，每年复审
• 不活跃账户：经过一定期限后提醒，无回应则匿名化
• 未回应的潜在客户：数月后删除
• 技术日志：30 至 90 天
• 财务审计轨迹：依内部控制与审计需要
• 未录用的应聘者数据：合理期限后删除，除非已获保存许可
• 客服录音：依质量与争议用途，而非永久保存

常见问题

永久保存所有数据更安全吗？

不是。未删除的数据仍需保护和备份，在泄露时可能成为负担。无目的的保存也违背数据保护原则。

客户要求删除但仍有未结账单怎么办？

为催收和履行账务义务所需的数据可以保留，并向客户说明。其余不需要的数据则删除或匿名化。

小企业也需要吗？

需要，只是规模简单。一页纸列明数据类型、保留期和负责人，再加上定期清理的习惯就够了。

匿名化就够了吗？

如果做得正确、无法再关联到个人，就够了。如果仍可通过组合数据识别出某人，那只是假名化，仍被视为个人数据。

结论

数据保留政策不是复杂的法律文件，而是一种运营习惯：知道自己保存了什么、为什么、保存到何时，以及如何放手。从盘点和一页纸的保留表开始，在系统中添加标记和定时任务，并在第一个请求到来之前测试好删除流程。这样风险、成本和合规负担会一起下降。