客戶要求刪除資料時，網站後台少一筆，不代表信箱、試算表、客戶系統、外包服務與備份都已處理。本文用五項驗收問題，協助企業確認身分、資料去向、保存依據、供應商責任與完成證據。
後台刪除，可能只是流程的第一站
客戶來信說：「請刪除我的資料。」同事在網站後台找到會員或詢價紀錄，按下刪除，再回覆已完成。問題是，同一份資料可能早已寄到客服信箱、同步進客戶關係管理系統（CRM，也就是集中追蹤客戶往來的工具）、匯出成試算表，或交給電子報與金流等服務商處理。畫面少一筆，只能證明那個畫面查不到，不能證明每個去向都已完成處理。
這像店家收到退貨，只從櫃檯帳本劃掉品項，卻沒有同步通知倉庫、會計與物流。每一站各自看起來合理，整體卻沒有真正結案。對企業而言，後果不只是不符客戶期待，也可能造成客服反覆查找、部門說法不一致、供應商責任不清，以及日後無法說明資料為何仍被使用。
刪除不是全部清空，而是先做正確判斷
台灣《個人資料保護法》第 3 條列有請求刪除，以及停止蒐集、處理或利用等權利；第 11 條則同時保留「執行職務或業務所必須」等例外。因此，收到請求後不宜一律立即全刪，也不能只用「系統做不到」結案。企業要先確認請求人身分、涉及哪些資料與用途，再釐清契約、會計、爭議處理或其他保存需求。第 4 條也把受託處理個資者納入規範，所以盤點不能停在自家網站，還要涵蓋實際接觸資料的服務商。本文提供的是系統與營運盤點方向，不取代個案法律判斷。
真正可驗收的流程，應把資料分成「仍在日常使用的主系統」、「已複製或匯出的工作檔」及「為災難復原保留的備份」。前兩類通常可以直接刪除、去識別化或停止使用；備份往往不能任意改寫，但應有隔離、存取限制、到期淘汰及還原後再次套用刪除要求的規則。不同平台的做法與期限不一，不能把單一供應商的說明當成所有系統的保證。
用五個問題驗收，而不是只看一張截圖
- 請求人怎麼核對？ 驗證強度要與資料敏感度相稱，避免只憑陌生信箱刪錯他人資料，也不要為驗證再蒐集不必要的證件。
- 資料在哪裡？ 除了網站資料庫，還要列出客服信箱、雲端硬碟、試算表、分析工具、CRM、行銷名單與受託廠商。
- 哪些要刪、哪些要留？ 每一類資料要有用途、保存依據、期限與負責人；有必要保留時，也要停止與原目的無關的日常使用。
- 供應商怎麼接棒？ 合約或服務文件應說明誰負責轉交請求、處理衍生副本、回報完成，以及服務終止後如何移交或刪除。
- 完成能怎麼證明？ 保留工單編號、處理日期、涵蓋系統、例外理由與負責角色。證據應記錄動作，不應再複製一份準備刪除的完整個資。
警訊很直接：沒有人能畫出資料去向；只有單一後台截圖；離職同事的匯出檔仍在個人雲端；供應商只說「已處理」卻說不出範圍；備份還原後，已刪資料會重新出現。如果出現其中一項，問題通常不在刪除按鈕，而在缺少跨系統的責任與驗收設計。
今天先做一張刪除路徑表
先挑一個常見入口，例如會員註冊或網站詢價，建立一張簡單表格：資料項目、進入位置、同步去向、用途、保存期限、負責人、刪除方式、供應商窗口與完成證據。接著用一筆測試資料走完整流程，確認信件附件、匯出檔、第三方平台與還原情境是否都被涵蓋。測試資料不要使用真實客戶身分。
便宜方案常見的差異，不一定是沒有刪除功能，而是只處理主資料庫，缺少跨工具清冊、供應商協調、例外審核與可追溯紀錄。小型團隊可先用人工工單與雙人覆核，不必急著建置昂貴平台；當請求量、資料敏感度或串接系統增加，再評估自動派工與刪除傳播。自動化能降低漏接，卻也會放大錯誤刪除，因此仍要保留身分核對、例外審核與失敗告警。
什麼情況值得找專業團隊盤點
如果資料只在一個可控系統、去向清楚，企業可以先自行建立表格、指定負責人並做一次演練。若網站、門市、廣告、CRM、金流與外包服務互相串接，無法確認備份與匯出檔，或各部門對保存理由說法不同，就需要一起盤點資料流、權限、合約責任、刪除機制與驗收測試，必要時再請法律或法遵專業確認保存依據。
準備接洽時，帶上資料入口清單、使用中的平台與廠商、現行隱私告知、保存規則、曾收到的請求類型，以及一份去除個資的處理紀錄，就能更快找出斷點。邊境部署可以協助把營運說法轉成可執行、可驗收的系統流程；若現況只需要一張清楚的人工清單，也會把自動化留在真正值得投入的階段。
查證來源：個人資料保護法第 3、4、5、11 條、NIST Privacy Framework、Google Cloud 資料刪除流程說明。