GDPR 資料當事人請求流程圖（由受理到結案）
GDPR 資料當事人請求流程圖：登記請求並起算一個月期限、核實身分、分流權利、搜尋系統與處理者、遮蔽第三方資料、必要時延期，最後回覆並記錄決定。
甚麼是gdpr 資料當事人請求流程圖（由受理到結案）流程
資料當事人請求出事的地方，幾乎從來不是大家事先演練過的那一段，而是最前面。請求往往只是一封投訴電郵最後那一句、客服對話裡的一段話，或者打去分行的一通電話，然後停留在一個並不知道「收到的那一刻法定時限已經開始計算」的人手上。等到隱私團隊收到的時候，一個月已經去了一半，搜尋還未開始。第二種失效，是把請求當成法律作業來做——它其實主要是搜尋與遮蔽的作業：真正花時間的，是找出每一個存有該人資料的系統，然後把取回來的資料逐份讀一次，看看裡面有沒有其他人的個人資料。第三種失效藏在身分核實裡：相稱的核實是在保護資料當事人，而不斷加碼索取證明文件則是拖延手段，監管機關一看就認得出來。把這三件事修好的流程，大部分請求都能從容地在一個月之內回覆完畢。
本圖畫的是公眾人士行使 GDPR（歐盟《一般資料保護規則》）權利時所走的法定路徑——一位客戶、一位前員工、一位求職者，或者曾經填過一張表格的人。它不是員工為了工作而取得某份資料集的內部路徑：那是一項普通的業務審批，有負責人、有用途、最後有一份使用授權，畫在 /yue/templates/資料存取申請流程 上。它亦不是取得系統或帳號的路徑——那是審批、職責分工與帳號開通，畫在 /yue/templates/存取申請流程 上。而它與 /yue/templates/資料外洩應變流程 正好是一體兩面：那張圖處理的是你們失去對個人資料的控制之後、按 72 小時計算的第 33 條與第 34 條通報責任；本圖處理的則是有人要求你們就手上的個人資料作出交代時、按一個月計算的時限。本圖所倚賴的隱私政策、保存期限表與處理活動紀錄本身都是受管制文件，它們的起草、審批與檢討週期在 /yue/templates/文件管制流程 上。
大部分書面程序留作預設的三件事，在這裡被明確畫成方格。「身分是否已確認？」有三條分支而不是兩條——已確認、需要更多證明、無法確認——所以索取證明會繞回同一道判斷，而不會靜靜變成無限期擱置；而一項始終無法證實的請求，會在「結案：身分無法確認」處有一個具名的終點，而不是在收件匣裡淡出。「是否明顯無理或過度？」在流程早段就公開地回答一次，因為第 12 條第 5 項把舉證責任放在控制者身上，而在最後一星期才得出的拒絕，看起來與「因為一個月用完了才拒絕」一模一樣。至於「請求是否複雜或數量眾多？」，它放在整理回覆之前而不是之後，因為兩個月的延期只有在你們已於首個月內連同理由告知請求人的情況下才存在。下游一切都匯合到同一條結案主軸上：全部提供、遮蔽、部分拒絕，或在「拒絕並說明理由及投訴權利」處徹底拒絕；而該請求仍然會在「記錄請求及各項決定」處寫進紀錄，仍然可以被升交，因為一項沒有人記錄的拒絕，正是監管機關最先聽到的那一項。
本流程圖涵蓋的內容
本範本包含
- 五條泳道——資料當事人、隱私受理小組、資料保護主任、法律顧問、系統與資料負責人——鋪在五個階段上：受理、身分核實、分流與範圍、搜尋與覆核，以及回覆與結案。
- 受理環節假定請求可以從任何地方進來：「經任何渠道收到請求」接上「登記請求並起算期限」，由此固定下時限所依據的收到日期，然後才是「確認收妥並說明預期」。
- 一道三向的「身分是否已確認？」判斷，其中索取證明那一支會經「索取相稱的身分證明」繞回同一道判斷，而第三條分支則為無法證實的請求給出一個誠實的終點「結案：身分無法確認」。
- 對實際行使哪一項權利的分流，接著是提早回答、且由控制者承擔舉證責任的「是否明顯無理或過度？」，其「是」分支走「拒絕並說明理由及投訴權利」；以及一道只容許提出一條澄清問題的「範圍是否清晰足以搜尋？」判斷。
- 搜尋與覆核的主軸：「搜尋系統、備份與處理者」、「覆核第三方資料與保密特權」、「適用豁免事由與拒絕理由」，以及把流程導向「延長兩個月並說明理由」的「請求是否複雜或數量眾多？」判斷。
- 一條連拒絕也會匯回的結案主軸：「是否涉及更正、刪除或限制處理？」會加上「執行並通知每一位接收者」，每一項已回覆的請求都會在「記錄請求及各項決定」處寫進紀錄，而「當事人是否質疑處理結果？」則把「已在期限內結案」與「已升交監管機關」分開。
何時使用本範本
- 你們要撰寫或更新資料當事人請求程序，需要用一頁圖說清楚誰登記、誰核實、誰搜尋、誰遮蔽、誰簽發回覆。
- 請求不斷落在客服收件匣、社交媒體專頁和前台接待處，你們需要時限由收到那一刻起算，而不是由隱私團隊聽說那一刻起算。
- 你們要培訓前線同事，而他們在這個流程裡唯一的工作，就是認得出這是一項請求，並在當日轉交出去。
- 你們試過超出期限，或者太遲才決定延期，希望把複雜度判斷放在整理回覆之前，而不是之後。
- 稽核人員、客戶或監管機關要求你們出示一份成文程序，而你們需要令遮蔽與豁免這兩步，以有具名負責人的步驟形態清楚顯示出來。
運作方式
把泳道改成你們自己的角色
把資料當事人、隱私受理小組、資料保護主任、法律顧問和系統與資料負責人，換成你們真正存在的角色。很多機構既沒有資料保護主任（DPO），也沒有內部法務：把這兩條泳道合併成一位隱私負責人，並寫明遇到疑難時你們會諮詢哪一家外部律師行，而不是在圖上畫一個從不覆核的覆核者。無論規模大小，都要把系統與資料負責人這條泳道獨立保留，因為搜尋是由營運那些系統的人執行，而不是由流程的主人執行。
把請求可能進來的每一條渠道列出來
請求不必是書面的，不必提到 GDPR，也不必送到隱私團隊手上。把它真正會走的每一條路寫下來——客服收件匣、聯絡表格、社交媒體、電話、郵寄信件、前台接待、直屬上司、律師信——並為每一條指派一位負責人，指示是當日原封轉交，不作評估。然後決定請求統一登記在哪一個地方，好讓收到日期存在於一個系統裡，而不是存在於某個人的寄件備份中。
在需要之前先寫好身分核實規則
事先決定每一類請求人各自要做甚麼核實：已登入的帳戶持有人、前員工、憑授權書代辦的第三方、代子女提出請求的家長。寫明哪一種證明可以消除哪一種疑問、保存多久、何時刪除。然後把你們的立場記錄下來：索取身分證明期間時限是否暫停——各地監管機關的指引並不一致，所以你們採取的立場要一致並且成文，而不是逐宗請求現場決定。
建立搜尋所依賴的系統清單
「搜尋系統、備份與處理者」的效果，取決於它背後那份清單。把處理活動紀錄轉成一份搜尋檢查表，逐一列明每一套應用系統、郵箱、共用磁碟、工單系統、閉路電視錄影、通話錄音存檔和受託處理者，並註明由誰執行搜尋、需時多久。再加上你們對備份與封存資料的既定立場。有檢查表，同一項請求做兩次會得出同一個結果——而這正是監管機關真正會查的地方。
訂定遮蔽與豁免的標準
把你們的準則掛在「覆核第三方資料與保密特權」上，令遮蔽不再是臨場發揮：甚麼情況下第三方的資料可以披露、甚麼情況下要徵求該人同意、甚麼情況下不經同意披露也屬合理，以及法律專業保密特權由誰、按甚麼方式主張。列出你們在自己司法管轄區內所援引的豁免事由，並要求每一項不予提供的內容都記下理由。沒有書面理由的遮蔽，幾個月之後由一個當時不在場的人來辯護，是辯護不了的。
在一個月之內排好內部日期，然後發佈
由期限倒推，為每一個步驟訂出自己的目標日期：第十日完成搜尋、第十八日完成覆核、第二十四日簽發。法定的一個月是外圍上限，不是計劃，而延期的決定必須在仍有時間通知對方的時候作出。如果你們同時受本地個人資料法例規管——例如香港《個人資料（私隱）條例》或台灣《個人資料保護法》——那裡另有一條自己的時限，與 GDPR 並不相同，通常更短，內部日期要按最先到期的那一個來排。然後帶著這張圖與受理小組、一位系統負責人和簽發回覆的人一起走一次，按他們實際的做法改正，再發佈該版本並保留此前的版本。
常見問題
資料當事人請求流程包含哪些步驟？
在請求進來的任何渠道上收到它，登記並由收到日期起算一個月期限，發出收妥確認，按比例核實請求人身分，分流出實際行使的是哪一項權利，判斷該請求是否明顯無理或過度，議定範圍——真正有需要時才提出一條聚焦的澄清問題，搜尋每一個可能存有相關資料的系統、備份與受託處理者，就取回的結果覆核當中的第三方資料與保密特權，適用任何豁免事由並逐項記下理由，判斷該請求是否複雜到需要兩個月延期並在需要時通知請求人，整理回覆及其理由，安全交付予已核實的當事人，記錄該請求及在其上作出的每一項決定，並告知請求人如有不滿可以如何投訴。實務中最常被跳過的是分流和遮蔽覆核這兩步，而它們正是產生投訴的兩步。
回覆資料當事人查閱請求有多長時間？
一個月。GDPR 第 12 條第 3 項要求控制者在無不當延誤的情況下、無論如何於收到請求後一個月內提供已採取措施的資訊。那是曆月而不是工作日的計算：由當月的日子算到下一個月的對應日；下一個月沒有對應日的，算到該月最後一日；對應日落在週末或公眾假期的，順延至下一個工作日。在請求複雜、或同一人提出多項請求的情況下，可以再延長兩個月，但條件是你們在首個月之內把延期及其理由告知請求人。索取身分證明或等待範圍澄清期間時限是否暫停，各地監管機關看法不一，所以要記下你們遵循哪一種立場並且一致執行。此外，如果你們同時受本地法例規管（例如香港《個人資料（私隱）條例》或台灣《個人資料保護法》），那裡另有一條自己的時限，通常比一個月短，實務上要按最先到期的一個來排內部日期。而實際上期限很少是在搜尋階段失掉的：它是在請求落在公司某處、到送抵負責回覆的人手上之間的那幾天裡失掉的。
可以拒絕資料當事人的請求嗎？
有時可以，但很少能以大家最先想到的理由拒絕。第 12 條第 5 項容許控制者在請求明顯無理或過度時收取合理費用或拒絕處理，而舉證責任在控制者身上。範圍寬、造成不便，或者是在爭議進行中提出的，都不等於過度。除此之外，各地法例另設豁免事由，容許你們不提供特定內容，而不是把整項請求都拒絕；第 17 條的刪除權亦附有條件：其第 3 項保留了法律規定必須保存、或為建立、行使、防禦法律請求所需要的資料。拒絕不等於不作回覆。你們仍然要在期限內答覆、說明理由，並告知對方可以向監管機關投訴及尋求司法救濟。所以本圖把拒絕畫成一個會產生回覆的步驟，它與其他所有結果一樣會被記錄，也一樣可以被升交，而不是讓一項被拒絕的請求靜靜掉出流程之外。
回覆裡涉及其他人的資料應該怎樣處理？
查閱權是取得請求人自己的個人資料，而不是取得每一份提到他的文件的副本；當材料是電郵往來、投訴檔案或考績紀錄時，兩者很容易混淆。第 15 條第 4 項訂明，取得複本的權利不得對他人的權利與自由造成不利影響。實務上，對每一項第三方資料有三個選項：遮蔽它、徵求該人同意披露，或者衡量資料的性質、該人是否負有保密義務、以及他是否已經拒絕，判斷不經同意披露是否合理。記下你們選了哪一個，以及為甚麼。覆核要在整理好的整套材料上做一次，而不是逐個系統做一次，由一位具名的人簽核，並保留一份未遮蔽的覆核版本，好讓決定日後受到質疑時仍然解釋得清楚。
本頁與資料存取申請流程圖有甚麼不同？
兩者向不同的對象負責。/yue/templates/資料存取申請流程 上的資料存取申請流程是內部的：一位員工或一個團隊為了完成工作而申請取用某份資料集，機構按用途、敏感度、合法依據與授權條款作出決定，然後批出一份範圍受限、有期限、可以撤回的權限。除了你們自己訂的服務時限之外沒有法定期限，而你們大可以直接說不。本頁則是一項由公眾人士行使的法定權利。期限來自第 12 條第 3 項而不是來自服務水平協議，結果是交出一份資料，而不是批出一項權限；而如果你們做錯了，對面那個人可以向監管機關投訴。如果你們要管的是公司內部誰可以查詢某張資料表，請用內部那一份範本；如果是外面的人在問你們手上有他的甚麼資料，請用這一份。