指南 · 合规
设计满足数据保护要求的业务系统
数据保护法律是一项法定义务，其大部分要求能否满足，取决于系统设计。本指南以泰国《个人数据保护法》（PDPA）为参照，为构建和运营业务软件的人员，将该法的主要义务转化为具体的功能和控制措施。
PDPA 对系统的要求
《个人数据保护法》（佛历 2562 年，即 2019 年）适用于收集、使用或披露泰国境内人员个人数据的组织。该法区分数据控制者（决定为何及如何处理数据）与数据处理者（代表控制者处理数据），并由个人数据保护委员会（PDPC）负责监督。该法规定了处理数据的合法依据、数据主体的权利、安全义务、记录保存义务以及数据泄露通知要求。
本指南仅供参考，不构成法律意见。该法及其配套法规和 PDPC 指引会随时间变化，具体如何适用于贵组织，应由您的数据保护官或法律顾问确认。以下内容从工程角度出发：凡法律要求组织必须能够做到的事项，本指南说明系统需要具备什么才能做到。
将合法依据作为数据字段
PDPA 认可多种处理个人数据的依据。实际要求是：对于系统所持有的每一类个人数据，组织都能说明适用哪种依据，并且系统的行为与之相符。
按用途记录依据
明确建模各项用途（薪资发放、订单履行、营销、欺诈防范），并为每项用途关联一种合法依据：同意、合同、法定义务、正当利益、重大利益或公共任务。将其保存在系统配置中以便出具报告，而不是只写在政策文件里。
单独处理敏感数据
健康、生物特征、宗教、犯罪记录等数据适用更严格的规定。应在数据结构层面标记这些字段，使其被加密、默认脱敏、排除在导出和分析之外，并仅在已记录特定依据的情况下才进行处理。
让依据决定系统行为
如果营销以同意为依据，系统就不得向未同意或已撤回同意的人发送营销信息，而且这一点必须在发送代码中强制执行，而不是靠提醒员工。如果保留以法定义务为依据，删除规则就应遵循该义务规定的期限。
可随时出示的同意记录
以同意为依据时，系统必须能够证明：某个特定的人在特定时间、以何种方式、针对特定措辞同意了特定用途。存储同意记录时应包含数据主体标识、用途、其所见告知或同意文本的版本、时间戳、渠道（网页表单、应用、纸质扫描件、电话）以及表单 ID 等证据。保留同意文本的每一个版本；如果记录所指向的文本后来已被改写，这条记录就什么也证明不了。
撤回同意必须与给予同意一样容易，并且必须在所有依据该同意采取过行动的系统中生效。应将同意设计为一个集中的状态，由下游系统（营销平台、新闻简报发送程序、分析流水线）在使用时实时检查，而不是复制一次就被遗忘的标记。我们网站的新闻简报就是这一模式的小例子：通过电子邮件进行双重确认订阅，每封邮件都附有退订链接，并在发送前应用屏蔽名单。
同意并不适合作为所有处理的依据。为发放薪资而处理员工数据，或为交付所购商品而处理客户数据，其依据是合同或法定义务；在这些情况下征求同意，反而会产生一项组织无法兑现的撤回权利。依据选择得准确，同意记录就会更少，也更有意义。
访问控制与数据最小化
该法要求采取适当的安全措施。从系统角度来说，这首先意味着最小权限：基于角色的访问控制，让每个角色只能看到其工作所需的字段。所有者 / 管理员 / 成员 / 查看者模型是工作区的可靠基础；业务应用通常需要更细的角色划分，例如仓库操作员能看到收货地址但看不到身份证号码，客服人员能看到银行卡末四位但永远看不到完整卡号。对于个人和敏感字段，在 API 层实施字段级脱敏，使任何客户端都无法绕过，值得投入。
最小化原则既适用于收集环节，也适用于每一份副本。只收集某项用途所需的字段；不要把生产环境的个人数据复制到测试和开发环境，而应生成测试数据或对数据进行匿名化处理；将导出和批量下载限制在确有需要的角色，并记录每一次操作。强身份认证为这一切提供保护：通过组织的身份提供方实现单点登录、双因素认证、在支持的地方使用通行密钥，以及与数据敏感程度相称的会话超时。
组织所依赖的数据处理者（托管、电子邮件、分析、AI 服务）需要通过合同约束其遵守同样的标准，架构也应清楚表明哪些个人数据流向了哪个处理者。
切实执行的保留与删除
个人数据只能在用途所需或法律要求的期限内保留。应将这一原则落实为按数据类别制定的保留计划，并注明期限及法律或业务理由：会计记录按税法要求的期限保留；求职者数据在录用决定作出后保留规定的时间；客户账户在不活跃达到规定期限后处理；客服聊天记录在规定时间后处理。然后将该计划自动化。依赖某人每年运行一次脚本的保留政策，算不上控制措施。
确定删除在技术上如何实现。软删除使数据不可见，但数据依然存在；它只适合作为硬删除或匿名化之前的短暂缓冲期。匿名化会删除或不可逆地转换标识信息，同时保留统计数据，使组织既能保留业务历史，又无需保留个人身份信息。备份也需要同样处理：规定备份的保存期限，确认备份已加密，并确保恢复的数据仍会执行备份之后发生的删除操作。
无需工程人员参与即可处理数据主体请求
数据主体可以询问组织持有哪些关于自己的数据，要求获取副本和更正，要求删除，反对或限制处理，以及撤回同意；数据控制者必须在法律和法规规定的期限内作出回应。系统层面的要求是：经过培训的员工无需工程人员协助即可处理这些请求，包括跨模块查找某人的所有记录、导出其个人数据的可读副本、更正字段并留下审计记录，以及在遵守必要保留规则的前提下执行删除或匿名化（发票不能因客户要求删除就删除，但可以在记录合法依据后予以保留）。
建立请求日志：谁提出了请求、何时提出、如何核实身份、做了哪些处理、何时完成。这份日志既能证明合规，也能显示哪些流程进展缓慢。
审计日志
审计日志记录谁在何时对哪些数据做了什么：登录、权限变更、个人数据的查看和导出、编辑和删除、配置变更。审计日志应由应用在操作发生时写入，与业务数据分开存储并限制写入权限，保留期限应审慎设定。如果日志与业务数据存放在同一数据库、由同一批管理员管理，就无法防范内部人员。
日志不仅要存在，还要有用：可按人员和记录搜索，定期审查，并对批量导出或非工作时间访问等异常情况发出告警。审计日志本身也包含个人数据，应纳入保留计划。
经过演练的数据泄露处理流程
该法要求数据控制者在发生个人数据泄露时，无不当延迟地通知 PDPC，并在可行的情况下于知悉后 72 小时内通知，除非该泄露不太可能对权利和自由构成风险；如果风险较高，还必须通知受影响的数据主体。七十二小时转瞬即逝。在系统层面做好准备，关键在于发现能力，即能够揭示未经授权访问的日志和监控，以及迅速查明受影响的是哪些数据、涉及哪些人、时间跨度多长的能力。
在组织层面，需要一份书面的事件处理流程：先通知谁、由谁评估风险、由谁起草通知、由谁与客户沟通，以及用组织使用的每种语言预先准备好的模板。每年以贴近实际的场景进行一次桌面演练，避免在真正发生泄露时才第一次使用运行手册。
准备情况检查清单
供数据保护官与工程负责人共同审查系统时使用。
- 每一类个人数据都对应一项用途和一种合法依据，并记录在系统中。
- 敏感数据在数据结构层面标记：加密、默认脱敏，并排除在导出和分析之外。
- 同意记录包含文本版本、时间戳和渠道；撤回同意会同步到所有据此采取行动的系统。
- 基于角色的访问控制，并在 API 中实施字段级脱敏；非生产环境中不含生产个人数据。
- SSO、双因素认证或通行密钥，以及与数据敏感程度相称的会话超时。
- 按类别制定保留计划，自动删除或匿名化，备份也包括在内。
- 由经过培训的员工使用集搜索、导出、更正、删除于一体的工具处理数据主体请求，并保存请求日志。
- 审计日志单独存储、限制写入、可供搜索、定期审查，并审慎设定保留期限。
- 数据泄露运行手册明确各方职责，备有每种工作语言的模板，并每年演练一次。
- 已与数据处理者签订合同，并记录流向每个处理者的数据。