個資保存期限怎麼訂：從資料清冊走到真正刪除

很多企業都有一條看起來正確的規則：個人資料只保存到業務需要的期限為止。但真正盤點時，資料往往散落在 CRM、客服信箱、共用硬碟、紙本文件、分析平台、測試環境與雲端備份裡。前端系統設定了會員刪除，資料倉儲卻還留著一份；合約終止後，委外廠商刪除了正式環境，備份磁帶和支援工單仍然可以還原原始資料。

這不是單純的 IT 清理問題。保存多久，涉及蒐集目的、法定保存義務、當事人刪除請求、訴訟或調查中的證據保存，以及企業能不能提出一套前後一致的決策紀錄。若企業只寫一個「永久保存」或「依業務需要」的欄位，通常等於沒有真正回答保存期限為何合理。

本文的切入點不是提供一張所有產業都能直接套用的年限表，而是說明企業如何建立可解釋、可執行、可驗證的保存與刪除治理。產業法規、會計、稅務、勞動、金融、醫療或訴訟保全要求，仍須由企業依實際情況確認，不能用本文取代法律意見。

一、先分清楚保存期限與資料生命週期

保存期限不是資料從建立到消失的單一數字。企業至少要區分四個時間點：蒐集或建立資料的時間、原始目的結束的時間、法律或業務理由允許繼續保存的期限，以及實際完成刪除或匿名化的時間。

例如，客戶帳戶關閉後，企業可能仍需要保存交易紀錄一段期間，以履行會計、稅務或爭議處理義務。但這不代表所有客服對話、行銷標籤、登入裝置資訊和內部備註都必須跟著保存。不同資料欄位的用途、風險和保存理由可能不同，應拆開管理。

臺灣個人資料保護法第 11 條規定，個人資料蒐集的特定目的消失或期限屆滿時，應主動或依當事人請求刪除、停止處理或利用；但因執行職務或業務所必須，或經當事人書面同意者，不在此限。同條也處理違法蒐集或利用時的刪除、停止蒐集、處理或利用義務。這個規定的重點，不是企業必須把所有資料立刻清空，而是企業要能說明資料為何仍有必要，以及必要性何時重新檢視。

如果企業同時服務歐洲居民，也要注意 GDPR 第 5 條第 1 項第 e 款的 storage limitation 原則：個人資料不得以可識別形式保存超過處理目的所必要的期間。英國 ICO 的指引進一步建議，企業應盡可能建立不同資料類別的標準保存期限，定期檢視，並在不再需要時刪除或匿名化。

二、保存期限不能從系統欄位開始，而要從目的開始

企業最常犯的錯，是先問「資料庫能保存多久」，再回頭替這個數字找理由。正確順序應該相反：先確認資料處理目的，再判斷目的何時結束，最後才把規則轉成系統與作業設定。

每一個處理活動至少應回答以下問題：

• 這批資料為何被蒐集？現在仍在支援哪一個具體目的？
• 目的結束的事件是什麼？帳戶關閉、契約終止、案件結案、員工離職，還是最後一次互動？
• 是否有法律、契約、爭議處理、稽核或安全調查理由需要繼續保存？
• 如果只需要證明曾經發生過交易或服務關係，是否可以只保存較少欄位？
• 是否可以匿名化或彙總，而不必繼續保留可識別個資？
• 期限到期時，哪些系統、報表、匯出檔、紙本與備份需要同步處理？

保存期限的理由要寫到足以讓未參與原決策的人看懂。例如，「會員資料保存七年」太模糊；「帳戶關閉後保存交易必要欄位七年，供會計與稅務查核；行銷偏好於帳戶關閉後停止使用並於三十日內刪除」才是可以進一步驗證的規則。實際年限仍應由企業依適用法規和產業要求確認，範例不是通用答案。

三、建立一張能真的下達刪除指令的保存清冊

保存清冊不應只是一張法遵部門的 Excel。它必須能連到資料擁有人、系統管理者、委外廠商和刪除證據。最小可行欄位可以包括：

這張清冊的價值，在於把「資料在哪裡」和「什麼時候該處理」連在一起。若企業只記錄應用系統名稱，卻沒有記錄匯出報表、共享信箱、客服錄音或供應商副本，期限到了也無法完成真正的刪除。

四、刪除不是按下 Delete，而是讓資料停止被使用

電子資料的刪除有不同層次。從使用者介面移到資源回收筒，通常不代表資料已經不可取回；從正式資料庫刪除，也不代表快取、索引、資料湖、分析副本和備份同步消失。企業應先定義「刪除完成」在不同系統中的技術意義，再建立可抽樣驗證的證據。

可以把刪除流程拆成五個動作：

1. 找出目標資料和所有已知複本，確認刪除範圍沒有漏掉下游系統。
2. 在正式環境停止使用，避免刪除期間仍被行銷、推薦或客服流程讀取。
3. 依系統能力執行刪除、不可逆匿名化或受控封存，並記錄執行時間與結果。
4. 對下游受託者、共享對象和報表平台發出刪除或停止利用指令。
5. 驗證查詢、權限、批次工作和抽樣還原結果，保存完成證明與例外原因。

如果資料因法律保全或調查而不能刪除，不能只在系統裡標註「暫緩」。企業應建立 legal hold 或調查保全紀錄，寫明保全範圍、核准人、理由、開始日期、定期檢視日期和解除條件。保全只應限制必要資料和必要期間，不能變成所有資料無限期保存的通用藉口。

五、備份是保存治理最容易被忽略的地方

備份管理常見兩種極端。第一種是說「備份不能刪，所以不用管」；第二種是為了每一筆刪除請求，立刻重建所有備份。兩者都不夠務實。企業應依資料風險、備份技術、還原流程與法規要求，決定可接受的處理方式。

較穩妥的設計通常包含以下幾點：

• 正式系統先完成刪除或匿名化，並防止已刪除資料在日常業務中重新被取出。
• 備份設定明確的保存週期、輪替規則和存取權限，不以「永遠保留」作為預設值。
• 在備份尚未自然淘汰前，建立還原後再次套用刪除清單的流程，避免災難復原把已刪資料帶回線上。
• 對高風險資料評估加密金鑰銷毀、不可逆遮蔽或隔離保存等方法，但不要把技術名詞直接當成已完成刪除的證明。
• 記錄備份範圍、媒介、保存期限、最後一次輪替、還原測試與刪除例外。

英國 ICO 的保存期限指引指出，如果適合從即時系統刪除個資，也應考慮刪除該系統備份中的資料；同時也承認電子資料不一定能立刻移除所有痕跡，重點是組織要讓資料不再被使用，並有清楚的備份保存與刪除安排。企業應把這段原則轉成自身的技術架構和風險決策，不要只把網路備份保留政策貼進個資制度。

六、委外退場要把刪除寫成可驗證的交付物

委外關係結束時，最常見的錯誤是只要求供應商「刪除資料」，卻沒有定義刪除哪些資料、包含哪些副本、何時完成、如何證明，以及法定保留或備份週期怎麼處理。契約終止通知寄出，不等於資料已經完成退場。

企業至少應在契約或資料處理協議中寫清楚：資料返還或刪除的選擇、正式環境與測試環境範圍、子處理者通知義務、備份自然淘汰或提前處理方式、刪除完成期限、例外保全程序、驗證權，以及供應商應交付的刪除聲明或技術紀錄。新加坡 PDPC 的個人資料處置指引也提醒，組織應有保存期限表和處置政策，外包處置時要評估第三方的作法；紙本銷毀還要處理暫存、運送、現場監督和銷毀證明。

刪除證明不必只是一張供應商自行簽署的聲明。企業可以搭配 API 執行紀錄、抽樣查詢結果、權限檢查、下游通知紀錄、備份輪替狀態和年度供應商查核。證據越接近實際控制，越能在稽核、當事人請求或爭議發生時說明企業做過什麼。

七、把保存與刪除納入日常管理，而不是年度大掃除

保存期限制度如果只在年度稽核前集中清理，通常會遇到三個問題：規則跟不上新系統、資料在期限內被複製到更多地方，以及沒有人知道例外何時解除。比較有效的做法，是把保存和刪除設成資料治理的日常觸發事件。

新增系統、改變處理目的、導入 AI 分析、增加跨境供應商、結束產品或服務、收到刪除請求、發生資安事件、進入訴訟或主管機關調查時，都應重新確認保存清冊。企業可以設定幾個簡單指標：逾期未刪資料筆數、尚未指定保存理由的資料活動數、刪除失敗率、例外保全逾期件數、委外退場完成率，以及備份還原後重新套用刪除規則的測試結果。

管理階層不需要先追求所有資料一次清零。更實際的順序是先處理高風險、用途已消失、容易被公開存取、跨系統複製最多，以及刪除後能立刻降低暴露面的資料。每完成一類，就保留決策理由、控制紀錄和改善結果，讓制度從一次性專案變成可持續運作的管理機制。

結論：保存期限是一個要能被問答的管理決策

企業真正需要的不是一張看似完整的保存年限表，而是一套能回答四個問題的治理：為什麼現在還要留？留到什麼時候？到期要怎麼刪？怎麼證明真的刪了？

臺灣個資法第 11 條提供了目的消失或期限屆滿後刪除、停止處理或利用的基本方向；英國 ICO 的 storage limitation 指引提醒企業建立可解釋的保存期限、定期檢視，並把備份納入刪除思考；新加坡 PDPC 的處置指引則把政策、保存期限表和第三方處置責任連在一起。企業可以借鏡這些共同原則，但仍須依自身產業法規、契約和實際資料流決定細節。

今天就能開始的最小版本，是挑一個資料類型，畫出它從蒐集、使用、複製、委外、備份到刪除的完整路徑，寫下保存理由、期限、責任人和驗證方式。只要這條路徑能被實際執行並留下證據，企業就已經從「我們應該會刪除」走向「我們可以證明資料何時、如何停止被使用」。

資料來源

• 臺灣個人資料保護法，全國法規資料庫（查詢日期：2026-09-13）
• Principle (e): Storage limitation，英國 ICO（查詢日期：2026-09-13）
• Guide to Disposal of Personal Data on Physical Medium，新加坡個資保護委員會（查詢日期：2026-09-13）
• Personal Data Protection Act，新加坡個資保護委員會（查詢日期：2026-09-13）