数据保护官不靠 IT 部门，能查客户网站的哪些地方
GDPR 第 32 条与客户的公开网站：数据保护官 20 分钟内可以独自检查的六件事，从外部看不到什么，以及如何带着日期把检查记录下来。
如果你是数据保护官（DPO）或 GDPR 顾问，一定经历过这样的时刻。处理活动记录整理好了，隐私声明写好了，处理者协议也签了。可是轮到网站，审查笔记里写着“待 IT 核实”。客户没有 IT 人员，建网站的公司也不回复。
然而，网站往往是客户运营的系统中，唯一一个接收互联网上任何人个人数据的：联系表单、邮件订阅、预约登记。其中相当一部分，你自己就能评估，不需要管理员权限，也不需要技术背景。下面讲怎么做，以及怎么记录。
第 32 条对网站有什么要求
《通用数据保护条例》（GDPR）第 32 条要求控制者和处理者“采取适当的技术和组织措施，以确保与风险相适应的安全水平”。其中列举的例子包括加密，系统持续的保密性、完整性、可用性和韧性，事件发生后及时恢复数据，以及“定期测试、评估和评价技术和组织措施有效性的流程”，目的是确保处理的安全。
落到公开网站上，就是几个具体的问题。表单数据在传到服务器的路上有没有加密？软件有没有保持更新？陌生人能不能下载含有个人数据的文件？网站有没有在没有法律依据的情况下把访问者的数据传给第三方？有没有人定期检查这一切并留下记录？
最后一个问题与问责原则相关。依据第 5(2) 条，控制者要对第 5(1) 条的各项原则负责，包括完整性和保密性，并且必须“能够证明遵守”这些原则。第 39(1)(b) 条把监督对 GDPR 的遵守情况，包括相关的审计，列为数据保护官的任务之一。一份注明日期的网站审查记录恰好属于这里。关于控制者一方的责任，包括 72 小时的泄露通报，见 GDPR 与你的网站。
20 分钟内你自己能查什么
下面的一切，任何访问者都能做到，所以你不需要任何权限。如果想对网站运行自动化扫描工具，请先问客户。每一步都截图，让网站地址和日期清晰可见。
**1. 小锁和证书。**点击网址旁的图标，打开证书详情。记下颁发机构和到期时间。然后手动输入地址，用 http:// 而不是 https://。网站应当自己跳转到 https 版本。如果停留在 http，表单数据可能是明文传输的。其余内容，包括过时的协议版本，可以用免费的 SSL 证书检查工具（英文）查看。
**2. 隐私政策。**每个页面的页脚和每个表单旁边有没有链接？链接能不能打开，还是指向 404？政策里写的控制者是不是真正运营网站的那个，有没有提到你在网站上能看到的那些工具？多年前写的政策，很容易和后来加了聊天插件或广告像素的网站脱节。
**3. 表单。**打开每个带表单的页面，看有没有小锁。从其他服务嵌入的表单，比如预约系统或邮件订阅工具，是数据的又一个接收方，需要与客户签订处理者协议。检查旁边有没有简短的隐私声明，以及表单要求填写的内容是否超出了目的所需。联系表单里出现身份证号字段，就值得和客户谈一谈。表单还可能出哪些问题，见你的联系表单是一扇门。
**4. 同意之前的 Cookie。**在隐身窗口打开网站，先不管 Cookie 横幅。按 F12，在 Chrome 或 Edge 里进入 Application 标签页，在 Firefox 里进入 Storage，打开 Cookie 列表。如果你什么都没点，分析或广告类 Cookie 就已经在了，比如 Google Analytics 的 _ga 或 Meta 像素的 _fbp，说明跟踪在没有同意的情况下就开始了。然后点击“拒绝”，刷新页面，看它们是否消失。事先同意的规则来自《电子隐私指令》（2002/58/EC）第 5(3) 条，以及各国据此制定的法律，而不是 GDPR 本身。这些工具所收集的个人数据则属于 GDPR 的范围。如果想不用 F12 先粗略过一遍，可以用 Cookie 同意前检查工具（英文），它会列出服务器设置的 Cookie 和页面代码里的跟踪器。由脚本稍后写入的 Cookie，只能在浏览器里看到。
**5. 域名下的邮件。**把客户的域名输入 SPF、DKIM 和 DMARC 检查工具（英文）。没有 DMARC 的话，任何人都可以发出看起来来自你客户的邮件，包括发给客户自己的客户，索要个人信息或付款。这是一种泄露风险，源头在网站之外，但用的是同一个域名。
**6. 能看到的软件版本。**按 Ctrl+U 查看页面源代码，搜索（Ctrl+F）generator。常常会找到类似 WordPress 6.x 的内容。把这个数字和 wordpress.org 上的最新版本比较。能看到版本号本身并不是漏洞，但版本很旧，说明插件多半也没人更新。如果找不到这个标签，也说明不了什么，因为它可以被隐藏。
从外部看不到什么
浏览器审查有局限，你的笔记应当像记录发现一样记录这些局限：
- 备份：是否存在，存在哪里，有没有人用它恢复过网站，
- 管理员账户：谁有管理员权限，是否启用了两步验证，
- 页面代码里看不到的插件版本，以及谁在负责更新，
- 提交发出之后会怎样：是否留在数据库里，留多久，进入哪个邮箱，
- 服务器配置、日志，以及数据库如何受到保护，
- 托管服务位于何处，数据是否离开欧洲经济区。
把这些变成给客户或其网站开发者的问题，并记下谁在什么时候回答的。没有回答也是一种结果，也要写进笔记。
如何记录这次审查
一年后有人问你当时是怎么知道的，审查记录应当经得起追问。统一用一种格式：
- 日期和时间，网站地址，检查人，使用的浏览器。
- 检查项清单，每一项标注为正常、需要修复，或无法检查。
- 每个需要修复的项目的截图。
- 发现的问题发给了谁，什么时候，以什么形式。
- 与控制者商定的修复期限，以及复查日期。
这样的记录对双方都有用。客户有了第 32(1)(d) 条所要求的定期测试的证据。你有了自己做过监督并转达过建议的证据。修复本身由控制者和为其建站的人负责。
至少每年重复一次审查，并在重大变化之后再做一次，比如更换了网站制作公司，或开了新的网店。两份注明日期的报告，可以表明你的建议有没有被落实。
客户很多的时候
客户有十几个以上时，逐个手动审查网站会占掉整天时间。外部检查的部分可以用 ShieldWave 自动完成。它像互联网上的任何人一样检查每个网站，包括暴露的文件、安全头和软件版本中的已知漏洞，并给你一份带日期的 PDF 报告，附有 GDPR 对应关系。技术部分可以原样交给客户的开发者，不需要再翻译。Pro 套餐每月 12 美元，最多 25 个网站。它不会证明符合 GDPR，也不查看管理后台内部，所以上一节里的那些问题，仍然需要你去问。