第一次读GDPR第32条时，我犯了大多数工程师都会犯的错——把它当成了法律文件。实际上它更像一份基础设施技术规范，只是用立法语言写成了条文。

“适当的技术措施”这个词组是全文最模糊、也最让人不安的地方。什么叫“适当”？什么算“技术措施”？谁来判断你做够了没有？合规顾问会给你一份50页的政策文档，而审计师会直接跳过文档，要求看你的数据库结构。你有没有证据能证明那些措施确实在运行？这才是审计师真正关心的。

打开网易新闻 查看精彩图片

我帮12家SaaS公司落地过第32条的技术控制项，每次都会冒出相同的九个控制项，也每次都会被问到相同的三个审计问题。这份指南就是针对这些反复出现的共性需求：九个你必须实现的技术控制项、每项的具体代码和命令、以及审计师会揪着你不放的五个问题。

先明确范围问题：在动手之前你要先搞清楚哪些数据受第32条管辖。GDPR第32条全称是“处理的安全性”，要求控制者和处理者根据风险等级采取适当的技术和组织措施。但多数团队漏掉了一个关键区别——第32条不是政策清单。政策只是说“我们会加密个人数据”，而证据要求的是“这是带自动轮换的KMS密钥、这是应用层加密代码、这是记录每次解密尝试的CloudTrail日志”。审计师要的是证据，不是文档。

四个核心要求覆盖了假名化与加密、持续保密性/完整性/可用性/韧性、事件后恢复能力，以及定期测试评估。听起来很抽象，但翻译成工程语言就很具体了：你要能证明数据落盘时是加密的、传输时是加密的、访问是有审计记录的、没被篡改过。

这套控制项在PostgreSQL上可以直接落地，比如用pgcrypto做字段级加密、配置自动空闲会话断开、用应用级日志补足CloudTrail覆盖不到的操作上下文。传输安全部分要求mTLS和TLS 1.3，完整性校验需要你能证明数据从写入后就没被动过。

如果你从零开始搭，整套控制项预计需要两到四周，单个控制项从30分钟（KMS密钥配置）到五天（全应用层加密改造）不等。前提条件也不复杂：熟悉PostgreSQL和基础SQL、了解AWS的KMS/RDS/CloudTrail、能读Python和Node.js代码、对GDPR有基本认知。工具上需要PostgreSQL 14+、有IAM管理员权限的AWS账号、Python 3.8及以上配合cryptography库，Node.js 16+。至于Vanta或OneTrust这类合规自动化工具，不是必需但建议配合使用，用来收集和整理证据。