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