GDPR 对活动主办方到底要求什么？

两个角色，义务落在其中一个身上

GDPR 不问谁拥有软件。它问谁做决定。

买一套平台，不会把你的义务转给它。 反而多出了一个你有责任选好的对象：第 28(1) 条规定，控制者只应使用「提供充分保证」、使处理符合本条例的处理者。这是采购义务。和 GDPR 的大部分不同，它在签字之前就能核对。

这条界线会移动。如果平台以自己的名义卖票、充当收款主体（Merchant of Record），它会对自己经手的支付数据自行作出决定，在这一部分很可能就是控制者。这也是你要弄清自己用的是哪一种平台的又一个理由。

和处理者的合同必须写什么

第 28(3) 条列出你和平台之间的合同必须约定什么。对选软件的人来说，这是条例里最有用的清单：短、强制，供应商要么有这些条款，要么没有。订阅签字之前先要数据处理协议，找这八条：

(a) 只按你的指示

只按你书面记载的指示处理参会人数据，包括任何向欧盟以外的转移

(b) 保密

获授权处理数据的每个人都受保密约束

(c) 安全

采取第 32 条要求的措施

(d) 子处理者

只在该条规定的条件下再委托其他处理者。子处理者名单从这里来

(e) 权利请求

帮你答复查阅、更正和删除请求

(f) 泄露和评估

帮你满足第 32 至 36 条：安全、泄露通知、影响评估

(g) 合同结束

按你的选择删除或返还全部数据，并删除已有副本

(h) 审计

向你提供证明合规所需的信息，并允许审计和检查

其中两条通常写得最单薄。第 (d) 点：没有一份最新的子处理者名单、以及各自所在国家，你就不知道谁持有参会人的数据。第 (g) 点：「删除或返还」值得钉死一个期限。没有时间表的删除承诺，很难拿来约束任何人。

饮食字段是特殊类别字段

第 9(1) 条禁止处理若干类个人数据，除非符合少数几项例外之一。其中有两类，并没有人特意要收集，却会出现在普通的报名表上：

• 与健康有关的数据。 第 4(15) 条把它定义为「与自然人的身体或精神健康有关……并揭示其健康状况」的数据。坚果过敏、乳糜泻、轮椅需求、用药备注，都算。
• 揭示宗教信仰的数据。 清真或犹太洁食的选择并不写明宗教，但能揭示宗教，这就够了。在 2022 年 8 月 1 日判决的 C-184/20 案中，欧盟法院认为，处理「可能间接揭示有关自然人的敏感信息」的数据，并不被排除在第 9 条的保护之外（第 127 段）。

健康和宗教不是第 9 条里仅有的类别，但它们是餐饮或无障碍问题会无意中收集到的两类。落到实际操作上：

• 从固定清单里问厨房需要的。 「素食、纯素、清真、犹太洁食、不含坚果、不含麸质、其他」收集的是用餐要求。一个标题为「饮食或医疗需求」的自由文本框，收集的是诊断。
• 要有一个站得住的依据。 当参会人给出「针对一个或多个特定目的的明示同意」时，第 9(2)(a) 条解除这项禁止。实际操作中：在问题旁边用一句大白话说明，回答只用于餐饮、不作他用，并且勾选框默认不勾选。
• 给餐饮方的是份数，不是姓名——除非确实需要姓名。 每个餐次十二份素食、三份清真，就回答了厨房的问题。一张写着姓名和健康状况的表，回答的是好几个没人问的问题。如果某个人的过敏信息确实关系到安全，就只交给为这位参会人服务的人，不要给整份运营名单。
• 活动之后删掉。 第 5(1)(e) 条，存储限制：能识别个人的数据，保存「不超过必要的期限」。去年的用餐选择，对任何事都不再必要。

同一条也是场次入口的人脸识别很难站得住脚的原因：用于识别个人的生物识别数据也在同一份清单上。场次准入和到场那篇讲这种情形。

你设成条件的同意，不是同意

拍照、摄像、把线索分享给展商、订阅电子报，这几处是活动表单最容易把「同意」这个词用错的地方：那其实并不是同意。第 7(4) 条给出了检验标准：

「在评估同意是否系自由作出时，应最大限度地考虑，除其他外，合同的履行（包括服务的提供）是否以同意处理履行该合同所不必要的个人数据为条件。」

说白了，票就是合同。如果参会人不同意被拍照用于营销、或不同意把资料交给赞助商，就完成不了报名，这份同意就不太可能算自由作出，因为这场活动没有这两样也能举行。

同意不是唯一的合法依据，对其中一些用途也不是最合适的。活动摄影适合哪一种依据，取决于影像怎么用、你在哪里运营，值得和你的法律顾问一次定下来。没有疑问的是，当你确实依赖同意时的做法：每种用途单独问，和条款分开，撤回要和同意一样容易。第 7(3) 条几乎就是用这些词说最后这一点。

数据去了哪里

参会人在欧盟、平台托管在欧盟以外，就是在把个人数据转移出欧盟。这件事有自己的规则。

目的地没有欧盟委员会的充分性决定时，第 46(1) 条只允许在已有「适当保障措施」、且相关个人享有可执行权利的情况下转移。多数平台依赖的保障措施，是委员会的标准数据保护条款，第 46(2)(c) 条，通常叫 SCCs。

三个问题就能把任何平台这件事定下来，答案该在书面上，不在销售电话里：

• 参会人数据存在哪里？ 一个国家，最好再有一个区域。
• 还有谁持有它？ 子处理者名单，以及各自运营所在的国家。
• 转移依据是什么？ 充分性决定，或 SCCs，要写明是哪一种。

能很快回答这三问的供应商，通常其余的工作也做了。答不上来的，这本身就说明了问题。

两个法定时限

条例里有两个固定期限，起点都比多数主办方以为的更早。

# 平台上的一次泄露：
  平台发现它
  → 告诉你「不得无故拖延」   第 33(2) 条
  → 你通知监管机构
    自知晓起 72 小时内        第 33(1) 条
# 参会人要求自己的数据：
  收到请求                      第 0 天
  → 你的答复到期                一个月
  → 可以再延长两个月，
    如果你在第一个月内
    说明并给出理由              第 12(3) 条

「不得无故拖延」里没有数字，所以要在数据处理协议里把它写成具体的小时数。之后的 72 小时归你用。第二个时限有同样的陷阱：请求进了一个没人负责的公共邮箱，一个月的期限就已经开始计时；发给平台客服而不是发给你的请求，需要尽快转交。合同第 (e) 点应该把这件事写具体。

实际会出什么问题

这些都出在日常的活动运营碰上上面这些规则的时候，所以每一条都该在设计表单时就预防，而不是等表单用完之后：

• 饮食框是自由文本。 它用参会人自己的话收集诊断、用药和宗教实践，然后这份文字被导出给只需要用餐份数的人。
• 餐饮导出上有姓名。 厨房需要每场的数字，收到的是一份带姓名的健康状况清单，通常通过邮件。
• 拍照同意是一个不勾就报不了名的框。 它读起来像同意，通不过第 7(4) 条的检验。
• 数据处理协议从未签署。 订阅签了，于是整整一年的报名，是在第 28(3) 条要求的东西一样都没有的情况下进行的。
• 去年的参会人数据还在。 没人决定保留，也没人决定删除。存储限制是一个决定，不是默认。
• 查阅请求进了公共邮箱。 没人负责，一个月的期限却在一天天过去。
• 把线索给展商，埋在条款里。 把参会人资料交给展商是另一个目的，埋起来正是让它难以辩护的原因。

软件真正帮得上的地方

四个地方。把参会人数据放进去之前，用它们来测一套系统，包括我们的：

• 购买之前就能读的数据处理协议。 覆盖第 28(3) 条全部八点，子处理者名单和托管位置附在上面，而不是口头答应。
• 特殊类别的回答，要按特殊类别来对待。 饮食或无障碍问题能不能只对需要的人开放，导出时能不能只出份数、不出带姓名的清单。
• 同意要单独记录。 每一项同意都和门票分开采集，记下同意了什么、什么时候同意的，并且可以单独撤回，不用取消报名。
• 删除真的会发生。 一场活动的参会人数据能否按你设的时间表删除或匿名化，单个参会人的删除请求能否办完而不用提客服工单。

这些都不替你选合法依据，也不替你写隐私声明。那些是关于你的活动和你的辖区的决定。条例期待它们在第一笔报名到来之前作出，不是在第一封请求之后。