個資事件：把通報壓力轉成可執行的應變流程

很多企業的個資事件應變計畫，寫在制度文件裡看起來很完整：有通報表單、有聯絡清單、有事件分級，也列出法務、資訊、客服和公關的分工。但真正發生事件時，最常見的問題不是不知道要做什麼，而是不知道現在先做哪一件事。

客服收到客戶反映帳戶異常，資訊人員看到一批可疑下載紀錄，委外廠商通知儲存環境可能遭到入侵。這些訊息都可能是資安事件，也可能進一步成為個人資料事故。團隊若一開始就急著追究責任、撰寫公告，反而可能破壞證據，讓攻擊持續，或在事實尚未釐清前對外做出錯誤承諾。

本文不把第一時間想像成可以查完全部真相的時間。它的目標比較務實：先把損害控制住，建立可信的事件時間線，讓後續的法律判斷與對外溝通有可靠基礎。

一、先把"資安事件"和"個資事故"分開判斷

兩者經常同時發生，但處理目的不完全相同。資安事件關注機密性、完整性和可用性，例如帳號遭接管、惡意程式感染或資料庫被未授權存取。個資事故則要進一步確認：是否涉及可識別自然人的資料、資料被誰取得或可能取得、對當事人造成什麼風險，以及企業是否有通知或通報義務。

因此，第一線不應該用"目前還不知道有沒有個資外洩"作為暫停處理的理由。比較好的做法是先把事件標記為"疑似涉及個人資料的資安事件"，同時啟動兩條線：資訊團隊負責控制與鑑識，個資或法務團隊負責風險與義務判斷。

臺灣個人資料保護法第 12 條要求，公務機關或非公務機關保有的個人資料檔案發生被竊取、洩漏、竄改或其他侵害時，應查明後以適當方式通知當事人。對非公務機關而言，若未依規定通報或採取應變措施，也可能面臨主管機關裁罰。實際適用仍要看事件性質、主管機關要求和個別產業規範，不能只用一張通用表格代替判斷。

二、第一時間的四個工作面

第一時間不是四個依序完成的步驟，而是四個要並行推進的工作面。企業可以用一張事件指揮板，把每個工作面的負責人、目前已知事實、待確認事項和下一個決策時間寫清楚。

1. 控制：先止血，但不要先刪資料

控制措施的重點，是降低事件繼續擴大的機會。常見動作包括停用被濫用的帳號、撤銷存取權杖、限制受影響 API、隔離主機、暫停批次匯出，或要求委外服務商先保留相關環境。這些動作都應記下執行時間、執行人、原因和影響範圍。

“重設所有密碼"不一定是好的第一個動作。如果沒有先確認哪些帳號、哪些權限和哪些端點受到影響，全面重設可能造成業務中斷，也可能讓攻擊者察覺並改變行為。比較穩妥的方式是先保存現場，再依風險分層處理高權限帳號、服務帳號和疑似遭濫用的使用者帳號。

如果事件涉及雲端服務或委外處理者，合約中的通報時間不能取代內部事件時鐘。企業應立即指定一位窗口要求對方提供：首次發現時間、影響服務、受影響資料類型、已採取的控制措施、證據保存方式，以及後續更新頻率。“我們正在調查"不是足夠的事件紀錄。

2. 證據：先保留可驗證的事實

事件發生時，團隊很容易在聊天工具裡交換零碎訊息，最後卻找不到誰在什麼時間做了什麼決定。建議建立單一事件紀錄，至少包含以下欄位：

• 發現時間與發現來源。
• 最早可疑活動的時間。
• 涉及的系統、資料庫、應用程式或供應商。
• 已觀察到的資料存取、下載、修改或刪除行為。
• 已採取的控制措施與可能造成的業務影響。
• 尚未確認的假設、負責確認的人員與預計完成時間。
• 每次決策的理由，以及決策所依據的證據。

日誌、雲端稽核紀錄、端點影像和郵件標頭應以唯讀或受控方式保存，並記錄取得來源。若必須先移除惡意程式或重建主機，也要在處理前保存必要證據。證據保存不是為了把事件變成刑事案件才需要，而是為了支撐後續的通報範圍、當事人通知內容、保險理賠和改善措施。

3. 判斷：先做可更新的風險假設

第一個小時通常沒有完整資料，所以風險判斷不應假裝精確。可以把目前結論寫成三種狀態：已確認、合理推定、尚待確認。例如，“已確認某服務帳號在非正常地點成功登入"是已確認；“該帳號可讀取會員資料表，因此會員資料可能被存取"是合理推定；“是否實際下載及下載筆數"則是尚待確認。

判斷範圍時，至少要問五個問題：

1. 哪些資料類型可能受到影響？一般聯絡資料、身分識別資料、財務資料、健康資料或帳密資料，風險不同。
2. 資料是被看見、複製、竄改、刪除，還是只是短暫無法使用？
3. 受影響的當事人是否可以被識別？資料是否包含可被拼接的欄位？
4. 攻擊者是否仍然能夠進入系統？如果可以，事件就還沒有完成控制。
5. 當事人能否採取降低風險的行動，例如更換密碼、停用卡片或提高警覺？

這些問題的答案會決定後續是否需要通知當事人、向主管機關通報，或依金融、醫療、電信等產業規範向其他機關報告。不要把"尚未知道實際下載數量"誤解成"尚未發生個資事故”。

4. 協調：把決策權寫出來

應變失敗常常不是技術能力不足，而是每個人都以為別人在決定。事件一開始就應指定事件指揮人，並明確寫出以下權責：

• 誰可以要求隔離系統或暫停服務。
• 誰負責判斷個資法與產業法規義務。
• 誰可以批准對當事人、客戶、媒體或合作夥伴的說明。
• 誰負責與供應商、保險公司、外部鑑識團隊聯絡。
• 誰維護事件時間線與決策紀錄。

大型企業可以由資安事件指揮中心統籌，小型企業則至少要指定一位主要負責人和一位代理人。關鍵不在職稱，而在於事件發生時，不需要重新召開會議討論誰有權做第一個決定。

三、對外通知不要等到所有答案都齊全

歐盟 GDPR 第 33 條要求，控制者在知悉具風險的個資外洩後，原則上應在無不當延遲的情況下，最遲 72 小時內通知監管機關；第 34 條則處理對高風險當事人的通知。即使企業主要營運在臺灣，只要涉及歐洲居民或其他受特定法域保護的資料，就可能需要另外評估適用規範。

通知的實務難點，是事件資料常常分批確認。這不代表只能選擇沉默或一次寫出完美公告。比較可行的做法，是先準備一份經過法律和資安確認的初步訊息，清楚區分已知事實、目前仍在調查的部分，以及當事人現在可以採取的措施。後續再依新證據更新。

通知文字至少應讓收件人知道：發生什麼事、可能涉及哪些資料、企業何時發現、已採取哪些控制措施、當事人可以做什麼，以及要透過哪個窗口取得協助。不要使用"為提供更好的服務，我們近期進行系統優化"這類無法讓當事人判斷風險的說法，也不要在尚未確認時保證"沒有任何資料被下載”。

新加坡個資保護委員會提供的資料外洩處理指引，使用 C.A.R.E. Framework 協助企業處理事件，並把自我評估、主管機關通報、受影響個人通知和事後檢討放在同一套流程裡。這個做法值得借鏡的地方，不是照抄外國通報門檻，而是把"判斷是否應通報"變成可以留下依據的工作，而不是主管臨時憑印象決定。

四、事件結束後，最重要的是找出控制失效點

事件被封鎖、服務恢復、公告發出，不代表改善工作完成。事後檢討應回答的不是"誰犯了錯”，而是控制為什麼沒有在更早的時間發現或阻止問題。可以從以下幾個角度檢查：

• 資料盤點是否能快速說明受影響資料表、欄位和當事人類型。
• 存取權限是否符合最小權限，離職或轉調帳號是否及時停用。
• 日誌是否足以辨識異常下載，且保存時間能支撐調查。
• 委外契約是否要求即時通報、證據保存和配合調查。
• 事件分級表是否讓第一線知道何時必須升級給個資或法務窗口。
• 通知範本是否真的能用清楚語言說明風險，而不是只有法律保留文字。
• 演練是否測試夜間、假日、主要負責人不在時的替代流程。

ISO/IEC 27001:2022 將資訊安全管理建立在風險管理、持續改善和組織責任上。對個資應變而言，這表示事件紀錄不應只在稽核前補做，而要回到風險評估、權限管理、供應商管理、教育訓練和管理階層檢討。英國 ICO 的 breach response guidance 也強調，實際事故和 near miss 都應集中記錄，並分析原因、影響、補救措施和再次發生的可能性。

五、企業可以今天就做的最小版本

如果企業還沒有完整的事件應變制度，不必先花幾個月寫出厚重手冊。可以先完成一頁式版本：一個事件信箱或電話、一張主要聯絡人清單、一個受控事件紀錄、一份第一小時檢查表，以及一個每 30 分鐘更新一次的決策節奏。

第一小時檢查表可以只寫八項：確認發現時間、指定事件指揮人、保存日誌與現場、控制持續存取、列出可能涉及的資料、區分已知與未知、通知個資和法務窗口、排定下一次更新時間。接著用一次桌上演練測試：如果凌晨兩點由委外廠商通知資料庫異常，誰接電話、誰能要求隔離、誰判斷是否通報、誰準備對外說明。

真正成熟的應變能力，不是保證企業永遠不會發生資料事故，而是事件發生時能在不製造更多混亂的情況下，快速保護當事人、保留事實、做出可說明的決策。第一個小時做得好，後面才有空間把法律、技術和信任的損害降到最低。

資料來源

• 臺灣個人資料保護法，全國法規資料庫（查詢日期：2026-09-09）
• GDPR 第 33 條與第 34 條，EUR-Lex（查詢日期：2026-09-09）
• Breach response and monitoring，英國 ICO（查詢日期：2026-09-09）
• Data breach management，新加坡個資保護委員會（查詢日期：2026-09-09）
• ISO/IEC 27001:2022，International Organization for Standardization（查詢日期：2026-09-09）