資料外洩應變流程圖（GDPR 72 小時時限）
個人資料外洩應變的泳道流程圖：遏制、對個人的風險判斷、72 小時內向監管機構通報，以及外洩事件登記冊。
甚麼是資料外洩應變流程圖（gdpr 72 小時時限）流程
個人資料外洩，是指任何導致個人資料被銷毀、遺失、篡改、披露或被未經授權存取的保安失效，無論出於意外還是出於故意。當中大多數並不是網絡攻擊。它們是一封發錯收件人的電郵、一份忘記刪掉隱藏工作表的試算表、一部遺留在火車上的手提電腦、一個向所有人開放的檔案共享、一份最終證明無法還原的備份。下面這個流程由懷疑觸發，而不是由已確認的結論觸發，因為法定時鐘由機構意識到可能發生了外洩的那一刻開始行走，而不是由調查完結時才開始行走。
這刻意不是一個保安事故應變流程。偵測、鑑證、證據保全、清除，以及驗證系統已經乾淨，都屬於那個流程，由保安團隊負責；在這裏，它們只表現為一個遏制步驟，以及一次把修復工作交回保安團隊的交接。如果外洩源於網絡攻擊，就把兩個流程一齊運行：技術應變負責復原並加固整個環境，而本圖在旁邊按自己的期限運行，回答的是另一個問題——必須通知誰、在甚麼時候之前通知，以及如果答案是不必通知任何人，你們要寫下甚麼。它亦不是 IT 事故管理，後者在服務恢復時就完結了；它同樣不是資料當事人查閱要求流程，那個流程處理的是個人索取自己的資料，而不是機構把資料弄丟了。
有兩個決策承擔着法律分量，而它們經常被彼此混淆。在歐盟與英國 GDPR 之下，向監管機構通報是預設動作：除非該外洩不太可能對個人的權利與自由構成風險，否則就必須通報。通知受影響的個人則是另一項獨立而門檻更高的判斷，只有在外洩很可能對他們構成高風險時才需要。一宗外洩完全可能需要向監管機構通報，卻從未通知涉及其中的那些人。團隊第三個容易漏掉的地方是：兩條分支最終會匯合——每一宗外洩都要進入內部登記冊，包括你們決定不通報的那些，並連同作出該決定的理由一併記錄。
本流程圖涵蓋的內容
本範本包含
- 五條角色泳道，每個步驟都有明確負責人（發現者／報告人、資訊保安、資料保障主任、法律、傳訊），橫跨五個階段欄：報告，評估與遏制，通報決策，通報執行，以及記錄與檢討。
- 報告階段：報告人泳道中的「發現可能的資料外洩」與「透過資料外洩通報渠道呈報」，隨後由資訊保安執行「登記呈報並啟動時間線」，從而確定 72 小時時限賴以起算的知悉時間點。
- 資訊保安泳道中的初步評估與遏制，隨後是由資料保障主任負責的「是否涉及個人資料？」決策，其「否」分支把個案作為純粹的保安事故結案，而不是把它一路拖過整條監管路徑。
- 資料保障主任泳道中的「評估嚴重程度與對個人的風險」，隨後由法律部門確認究竟哪些通報責任真正適用，然後才是「是否需要向監管機構通報？」這項決策。
- 須通報的分支走「草擬通報並經法律審閱」和「在 72 小時內向監管機構通報」；毋須通報的分支則改走「記錄不予通報的理由」，令決策無論走向哪一邊都留有證據。
- 一個獨立的「對個人是否構成高風險？」決策，把工作交給傳訊部門去草擬並發出面向受影響個人的通知；隨後是兩條分支都會到達的外洩登記冊記錄、由資訊保安執行的補救措施、事後檢討與結案。
何時使用本範本
- 你們正在編寫或更新個人資料外洩處理程序，需要一頁紙說明誰評估、誰決策、誰通報。
- 你們希望把是否需要通報這件事提前定下來，這樣星期五下午五點就不會有人仍在爭論時鐘到底有沒有開始行走。
- 你們正在做資料外洩演練，希望端到端地檢驗整條 72 小時路徑，包括真正耗掉大部分時間的草擬與簽批步驟。
- 你們正在培訓員工該呈報甚麼、呈報去哪裏——因為幾乎每一宗真實外洩的第一步，都是一位普通員工留意到有不妥。
- 審核師或客戶要求你們出示一份成文的資料外洩處理程序（圖示是程序的證據，但它本身並不能證明合規）。
運作方式
為角色和呈報渠道命名
把這五條泳道換成你們真正擁有的角色。規模較細的機構往往沒有資料保障主任，會把這條泳道併入法律部門或某位私隱負責人；亦有機構會為外部資料外洩法律顧問或網絡保險公司另開一條泳道。然後把實際的呈報路徑寫進「透過資料外洩通報渠道呈報」這一步：一個郵箱、一張表格、一個電話號碼，以及一條規則——發現可疑就呈報，而不是先自己調查。
確定你們的監管機構和你們的期限
修改「確認適用的通報責任」這一步，寫明適用於你們的一個或多個監管機構、跨境營運時的主導監管機構，以及你們所處的行業性制度或歐盟以外的其他制度。這些制度按不同的時鐘運行，因此把每一個都寫下來，而不要假定 72 小時就能涵蓋一切。同時補上與客戶之間的合約通知期限，它們往往比法定期限更短。
把你們的風險判斷準則寫下來
在「評估嚴重程度與對個人的風險」上附上你們自己的準則：資料的類型與敏感度、涉及的個人與紀錄數量、這些人被識別出來的難易程度、資料是否已加密或以其他方式無法使用、當中是否包含弱勢人士，以及損害的嚴重程度與發生可能性。事先寫好的準則，正是令那兩個決策在事後站得住腳的東西。
指定這兩個決策和簽批人
在圖上寫明誰負責「是否需要向監管機構通報？」和「對個人是否構成高風險？」，誰有權批准提交給監管機構的通報，以及誰可以批准發給個人的措辭。為每一項都設一位替補——資料外洩不會等人放完年假。
在 72 小時之內設定內部子期限
由最後限期向回推算，為中間各步驟設定目標時間：資料保障主任何時必須收到評估、草稿何時必須送達法律部門、簽批何時截止。法定限期是外沿，不是計劃——而小時數真正流失的地方，正是草擬與審批。
把登記步驟指向你們真實的登記冊，並為圖做版本管理
把「在登記冊中記錄該外洩」連到你們實際維護的那份紀錄上，並列出它必須包含的欄位：外洩的事實經過、造成的影響、已採取的補救措施，以及每一次通報決策的理由，包括那些否定的決策。然後把圖發給資料保障主任、法律、資訊保安和傳訊部門審批，並保留獲批版本，令你們演練的程序就是你們發布的程序。
常見問題
72 小時的外洩通報時限由甚麼時候開始計算？
在歐盟與英國 GDPR 之下，控制者必須在知悉發生個人資料外洩之後，不得無故拖延地、並在可行的情況下不遲於 72 小時內向監管機構通報。知悉是指已經有合理程度的確信，認為一宗保安事故導致個人資料受到損害，因此短暫的初步核實是可以接受的；但你們不能靠拉長調查來推遲時鐘。這 72 小時是自然小時，不是工作小時：週末與公眾假期都在窗口之內。這正是本圖把「登記呈報並啟動時間線」放在最前面，並記錄誰在甚麼時候報告了甚麼的原因。
向監管機構通報和通知個人有甚麼分別？
它們是門檻不同的兩項判斷，這也是本圖把它們畫成兩個決策而不是一個的原因。除非該外洩不太可能對個人的權利與自由構成風險，否則必須通知監管機構——所以通報實際上是預設動作。只有當外洩很可能對受影響的個人構成高風險時，才必須通知他們本人，而且存在公認的例外，例如資料已加密而仍然無法解讀，或者你們此後已採取措施，令高風險不再可能成為現實。因此一宗外洩完全可能已通報監管機構，卻從未通知涉及其中的那些人。
我們決定不通報的外洩，仍然需要記錄嗎？
需要。GDPR 要求控制者記錄每一宗個人資料外洩，包括事實經過、造成的影響和已採取的補救措施，無論是否已通報。實際上，你們選擇不通報的那一宗，其紀錄反而更重要，因為它是唯一能證明該決定出於論證而非出於方便的證據。這正是本圖中「毋須通報」分支要經過「記錄不予通報的理由」，而兩條分支最終都匯入登記冊的原因。
這與保安事故應變流程有甚麼不同？
保安事故應變流程關注的是攻擊者和整個環境：偵測、分流、保全證據、遏制、清除、驗證系統已經乾淨、恢復服務。本流程關注的是資料受到影響的那些人，以及隨之而來的責任；它由任何一宗個人資料外洩觸發，包括那些根本沒有攻擊者的情況，例如一封發錯的電郵或一份無法還原的備份。兩者在遏制環節和通報分支上重疊；遇上網絡事故時，你們會並行運行它們，由保安團隊負責技術那條線，由資料保障主任負責這一條。
如果我們是處理者而不是控制者呢？
處理者既不向監管機構通報，亦不通知個人。它必須在知悉個人資料外洩之後不得無故拖延地通知控制者，之後由控制者進行評估並作出兩項通報決策。如果這就是你們的處境，就把本圖裁到「是否需要向監管機構通報？」這項決策為止，用你們向控制者發出的通知取而代之，並檢查你們的合約——資料處理協議通常會訂明一個固定的內部限期，比控制者的 72 小時短得多。