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) 條全部八點，子處理者名單和託管位置附在上面，而不是口頭答應。
• 特殊類別的回答，要按特殊類別來對待。 飲食或無障礙問題能不能只對需要的人開放，匯出時能不能只出份數、不出帶姓名的清單。
• 同意要單獨記錄。 每一項同意都和門票分開蒐集，記下同意了什麼、什麼時候同意的，並且可以單獨撤回，不用取消報名。
• 刪除真的會發生。 一場活動的參加者資料能否按你設的時間表刪除或匿名化，單個參加者的刪除請求能否辦完而不用開客服工單。

這些都不替你選合法依據，也不替你寫隱私聲明。那些是關於你的活動和你的轄區的決定。條例期待它們在第一筆報名到來之前作出，不是在第一封請求之後。