GDPR 与你的网站：作为所有者，你要负什么责任

联系表单、邮件订阅、预约登记、网店里的客户账户。每一个都会收集姓名、邮箱，有时还有电话。依据通用数据保护条例（GDPR），这些是个人数据，而你的企业就是它的控制者。

许多所有者以为，网站是某家公司做的，服务器是某家主机商在运行，所以安全是他们的事。事情不是这样的。开发者和主机商有他们自己的义务，但你作为控制者，要对监管机构和你的客户负责。

下面用大白话讲讲，规则对你这个所有者有什么要求。这不是法律意见，遇到不寻常的情况，请咨询律师或你的数据保护官。

你的网站上谁是谁

GDPR 把相关方分成两种角色。控制者决定为什么收集数据、怎么收集。这就是你的企业。处理者代表你处理数据：数据库所在服务器的主机商，能进入管理后台的开发者或网站制作公司，邮件订阅工具，预约系统。

这有实际的后果。如果制作公司疏于更新，有人偷走了表单提交的数据，要报告泄露、通知客户、回答监管机构问题的人是你。事后你再按合同（如果有的话）和制作公司算账。

第 32 条：与风险相适应的安全措施

第 32 条不会告诉你用哪个插件，也不会规定密码要多长。它要求的是“适当的技术和组织措施”，也就是与风险相称的措施。它给出了几个例子：加密，保持数据的保密性和可用性，事件发生后能迅速恢复数据，以及定期测试你的安全措施是否真的有效。

落到小企业的网站上，是相当朴实的几件事：

• 整个网站运行在 HTTPS 上，没有任何表单通过普通的 http 发送数据，
• CMS、主题和插件按计划更新，而不是想起来才更新，
• 只有确实需要的人才能登录管理后台，并且使用两步验证，
• 备份存放在网站服务器之外，并且有人确认过恢复是可行的，
• 旧的表单提交内容不会无缘无故在数据库里留上好几年，
• 隔一段时间，就有人从外部检查网站，比如用安全扫描工具，并把结果记下来。

最后一点最容易被略过，却直接回应了“定期测试”这一要求。假如监管机构问起你怎么管安全，一条“3 月 3 日检测，发现两个问题，3 月 10 日修复”的记录，胜过任何“网站大概没问题”的保证。

向监管机构报告的 72 小时

个人数据泄露不一定是惊天动地的黑客攻击。它可能是任何人都能从某个公开地址下载的表单提交导出文件。可能是一个被劫持的管理员账户。也可能是给全体客户发的一封邮件，把他们的地址放进了抄送，而不是密送。

第 33 条规定，控制者应当不得无故拖延地通知监管机构，并且在可行的情况下，在得知泄露后 72 小时内通知。在波兰，这个机构是 UODO，在英国是 ICO（英国 GDPR 保留了同样的规则），在爱尔兰是数据保护委员会。这里指的是钟点，所以周末不会让计时暂停。只有当泄露不太可能给相关数据主体带来风险时，才可以不通报。

有两点应该让这件事不那么吓人。你不需要一上来就掌握全部情况：规则允许分阶段提供信息，所以与其等开发者交来完整的报告，不如按时报告你已知的，之后再补充。另外，大多数监管机构都在网站上提供在线表单来受理通报。

迟报的话，必须解释延误的原因。所以要和负责你网站的人约定，任何疑似泄露，当天就要让你知道。处理者必须不得无故拖延地告知你，但是否报告由你决定，期限也是你的。

什么时候必须告知你的客户

第 34 条又往前走了一步。如果泄露很可能给受影响的人带来高风险，你也必须告诉他们，同样要不得无故拖延。用大白话说：发生了什么，可能有什么后果，你做了什么，他们该留意什么，例如冒充你的企业发来的邮件。

高风险指的是这样的情况：客户账户的密码泄露，身份证号码，诊所登记表上的健康信息，或者律师事务所带有案件备注的客户名单。邮件订阅里的一个邮箱地址，通常没那么严重，但评估总是取决于具体情况。

也有例外。如果数据已经加密，外人无法读取，或者你立刻采取了措施，使高风险不太可能发生，就不必通知当事人。如果逐个联系所有人需要付出不成比例的努力，可以改为公开声明。

与主机商和开发者的处理协议

任何代表你处理个人数据的人，都应该与你签订数据处理协议（第 28 条）。它不必是一份很厚的文件。较大的主机商和邮件订阅工具，通常在后台或服务条款里就有现成的数据处理协议（DPA）。你接受它，并保留一份副本。

对自由职业者和小型制作公司，往往没有人想过这件事。协议里写明了，其中包括：他们只按你的指示处理数据，保证数据安全，发生泄露时协助你，在合作结束时删除或归还数据。再补上实际的细节：联系人是谁，通过什么渠道报告事件，多快报告。

哪些东西要留书面记录

GDPR 建立在问责之上。仅仅合规是不够的，你还要能证明。对企业网站而言，这意味着一个文件夹，纸质的或放在共享盘里都可以：

1. 与主机商、开发者或制作公司，以及每个接收表单数据的工具签订的处理协议。
2. 对你的安全措施的简短说明：什么东西由谁更新，备份在哪里，谁有管理员权限。
3. 对网站定期检查的结果，以及针对结果采取了什么措施的记录。
4. 泄露登记簿。第 33 条要求你记录每一起泄露，包括你决定不报告的那些：发生了什么，造成了什么影响，你做了什么。对于未报告的，写明你决定不报告的理由。
5. 处理活动记录，如果适用于你的话。对员工少于 250 人的组织的豁免，范围比看上去的要窄：它不涵盖不止偶尔发生的处理，而每周都带来咨询的表单，很难算作偶尔。

这一切不需要大笔预算。需要的是，在事情发生之前，先把谁做什么约定清楚。出了事件，72 小时过得很快，尤其是当你把第一天都花在弄清楚谁能进入服务器上的时候。