網站上的聯絡表單、報名表單、訂閱欄位，幾乎每個站台都有，但多數站長對它收集的資料怎麼處理、要留多久、使用者可不可以要求刪除，心裡並沒有明確的答案。這不是有沒有在意的問題，而是台灣《個人資料保護法》（以下簡稱個資法）與歐盟《一般資料保護規則》（GDPR）都有具體規定，忽略的後果是可舉報的違規，而非抽象的道德壓力。
實務上，有對象在歐洲的台灣站台，同時受兩套法規約束。即使訪客全在台灣，個資法仍要求網站說清楚收集用途，並保障當事人的查詢、更正、刪除權利。本文從最常見的表單場景出發，整理一份可直接對照的合規參考，並說明 WordPress 外掛端如何設定，將自動化機制接上去。
表單必備的同意聲明要寫什麼
表單送出前，使用者需要知道的事集中在三件：誰在收集資料、用來做什麼、同意或拒絕後會發生什麼。個資法第 8 條要求在蒐集時告知蒐集機關（即網站本身）、蒐集目的、使用範圍，以及當事人的各項權利。GDPR 的要求稍微更細，必須同時說明保存期限與資料控管者的聯絡方式。
聲明不需要做成長篇隱私政策的連結。最直接的做法是在送出按鈕上方加一段簡短說明，約兩到三句，再連結到完整的隱私政策頁面。以下三項是聲明裡不能省的核心內容。
- 蒐集目的說明：具體說明這份表單收集資料的用途，例如「本表單資料僅用於回覆您的詢問，不會轉交第三方」，比泛稱「優化服務」更具體、也更合規。
- 同意勾選框：不能預先打勾，必須讓使用者主動勾選表示同意。GDPR 明確要求同意行為必須是「明確、自願、具體且知情」的積極動作，預先勾選一律不算有效同意。
- 撤回說明：告知使用者可透過寄信或帳號設定撤回同意，並說明撤回後網站會在多少天內刪除其資料。
同意聲明的文字愈具體，合規程度愈高。「本網站遵守相關法令」這類空洞承諾，對使用者沒有意義，對監管機關也沒有保護效果。
個資保存期限的上限在哪裡
個資不能無限期保存，但實務上很多站台從未清理過表單收件匣裡的資料。個資法第 11 條要求：蒐集目的消失或期限屆滿後，應主動或依請求刪除個資。GDPR 的「儲存限制原則」（Storage Limitation）同樣要求不得超過必要期間持續保存可識別身份的資料。
問題在於「必要期間」究竟是多長。法律沒有給固定數字，而是要求與蒐集目的掛鉤。幾個常見的表單類型，業界慣例與合理推估如下。
| 表單類型 | 合理保存期 | 依據邏輯 |
|---|---|---|
| 聯絡詢問（未成交） | 6 個月 | 詢問未成案，蒐集目的於回覆後消滅 |
| 聯絡詢問（已成交） | 5 年 | 消費者保護法規範的消費爭議時效 |
| 電子報訂閱 | 訂閱有效期間 | 目的存續中；退訂後立即刪除 |
| 活動報名 | 活動結束後 3 個月 | 活動服務完成，蒐集目的消滅 |
| 求職應徵 | 最長 1 年 | 勞動市場慣例，超過需重新取得同意 |
這個表格的數字是「不踩底線的參考上限」，不是說保存到這些天數就一定合規。如果有業務上的理由需要保存更久，必須在隱私政策裡明確說明，並確保後台有對應的處理紀錄。
使用者的刪除請求，站台必須做到哪些事
個資法第 11 條第 3 款與 GDPR 第 17 條（被遺忘權）都賦予使用者請求刪除的權利，差別在 GDPR 的範圍更廣、時限更嚴格。通常的規範要求是收到請求後 30 個日曆天內完成刪除，GDPR 允許延長至 90 天，但必須書面告知延遲原因。
對站長來說，「刪除」不只是把某筆表單記錄從後台移除，還涵蓋幾個容易被遺漏的位置。
- 電子郵件通知信件：Contact Form 7（聯絡表單 7）或 WPForms 等外掛送出後通常會寄一封通知信到管理員信箱，這封信本身也含有個資。刪除後台記錄之後，信件那份資料也需要一併處理。
- 外掛整合的第三方系統：表單若有串接客戶關係管理系統（CRM）或電子郵件行銷平台，刪除請求必須同步傳至那些系統，單獨刪除 WordPress 端並不完整。
- 備份檔案：主機備份會把已刪除的資料保留一段時間。需在流程上明確訂定定期清除備份中的個資，或在備份到期後不再還原特定使用者資料。
收到刪除請求時，建議在信件裡或站台後台記一筆處理記錄，包含請求日期、回覆日期、刪除完成日期。這不是多餘的行政工作，而是面對查核時能夠舉證的唯一方式。
WordPress 表單外掛的自動清除與資料匯出設定
手動管理大量表單記錄容易遺漏，靠外掛的自動化功能才是可持續的做法。主流表單外掛在這方面的功能分布如下。
WPForms 的記錄到期設定
WPForms Pro 版有「Entry Expiration」設定，可以針對每個表單指定自動刪除的天數。設定路徑在 WPForms → Settings → GDPR Enhancements，以及各表單的 Settings → General 底部。啟用後，到期的送出記錄會在 WordPress cron 觸發時自動清除，不需人工介入。
同欄位頁面還有「Disable User Cookies」與「Disable User Details」兩個開關：前者關掉送出時自動記錄的 Cookie，後者停止紀錄 IP 位址與使用者代理字串（User Agent）。兩者對降低資料庫中可識別身份資訊的密度很有幫助，尤其對沒有正當業務需要記錄 IP 的聯絡表單，應預設關閉。
資料匯出方面，WPForms 可以在送出記錄列表選取特定記錄後匯出為 CSV，供收到存取請求時使用。
Gravity Forms 的保存期設定與個資匯出
Gravity Forms 的自動清除在 Forms → Settings → GDPR 底下，稱為「Retention Period」，同樣可以對每個表單獨立設定。超過保存期的記錄會標記為待刪，在下次排程作業執行時清除。
該外掛另有「Personal Data」欄位標記機制，可以在表單欄位設定中將某欄標記為含有個人資料。收到刪除請求時，進入 Forms → Personal Data → Erasure Requests 輸入使用者 Email，系統會自動搜尋所有含有該地址的送出記錄並逐一清除，同時可以跳過法律依據上需要保留的記錄，例如已完成的訂單記錄。
存取請求（使用者要求查看自己的資料）走 Forms → Personal Data → Export Requests，操作邏輯相同。
Contact Form 7 搭配外掛補足記錄功能
Contact Form 7 本身不保存送出記錄，資料只走 Email，這讓自動清除的必要性降低，但也讓存取請求的回覆更難處理。如果需要在後台保存記錄，必須搭配 Flamingo 外掛；有了記錄，才能搭配像是 GDPR for Contact Form 7 這類外掛，加入同意勾選框與自動清除邏輯。
對每月送出量不多的小站，Contact Form 7 加 Flamingo 的組合相對輕量。對表單流量大、需要完整稽核軌跡的站台，WPForms 或 Gravity Forms 的原生功能支援則更完整。
從風險高低決定動工順序
知道要做什麼之後，接下來要判斷哪些先動。風險最高的是同意聲明——這是個資合規要求中最直接可見、也最容易被使用者主動舉報的部分。每個現有表單的送出按鈕前，是否有具體說明蒐集目的、是否要求主動勾選而非預設打勾，應優先逐一檢查。
同意聲明需要連結到隱私政策頁面。若站台沒有獨立的隱私政策頁，或內容沒有說明保存期限、使用者權利、聯絡方式，這個缺口應與聲明同步補上，否則連結指向空處，反而形成更明顯的漏洞。
外掛設定層面，依照前述各外掛的設定路徑，對聯絡表單設定不超過 6 個月的保存期，對電子報訂閱表單設定退訂後立即清除的觸發邏輯。同時評估是否有正當理由保留 IP 記錄，如無必要則關閉，減少可識別資料的儲存量。
最後一步是刪除請求的處理流程。在後台或內部文件裡訂定一套簡單的作業方式——從哪裡收到請求、由誰確認、多少天內完成、完成後記錄在哪裡。流程本身比工具更關鍵，沒有人執行的自動化設定，遇到查核時仍舉不出有效的處理紀錄。