台灣個資法下 B2B 電商顧客資料刪除請求處理 SOP

台灣個資法（PIPA）第 11 條與第 13 條要求非公務機關在收到當事人刪除請求後 30 日內處理，必要時得延長 30 日一次。B2B 電商的正確做法是：驗證身分、界定範圍、比對法定留存義務、對可刪資料執行硬刪除、對必須留存者匿名化封存，並留下稽核軌跡。

這篇教學給的是可以直接落地的 SOP：從受理表單、身分驗證、跨系統刪除鏈（Shopify、HubSpot、資料倉儲、備份），到回覆信範本與稽核證據。B2B 情境比 B2C 麻煩得多——你刪的往往不是「消費者」，而是某家經銷商的採購窗口，而那筆訂單的發票還躺在你必須保存五年的會計憑證裡。

台灣個資法對刪除請求的法律基礎是什麼？

先把條文對齊，SOP 才站得住腳。以下條文依據全國法規資料庫公告之《個人資料保護法》現行條文：

• 第 3 條：當事人就其個人資料享有查詢、閱覽、製給複製本、補充或更正、請求停止蒐集處理利用、請求刪除等權利，且「不得預先拋棄或以特約限制之」。這代表你在 B2B 合約裡寫「客戶同意放棄刪除權」是無效的。
• 第 11 條第 3 項：個人資料蒐集之特定目的消失或期限屆滿時，應主動或依當事人請求，刪除、停止處理或利用。但「因執行職務或業務所必須」或「經當事人書面同意」者，不在此限。這一項是你保留交易紀錄的主要法律出口。
• 第 13 條第 2 項：非公務機關受理第 11 條之請求，應於 30 日內處理；必要時得予延長，延長之期間不得逾 30 日，並應將其原因以書面通知請求人。
• 施行細則第 6 條：所謂「刪除」，指使已儲存之個人資料自個人資料檔案中消失。這個定義很重要——把資料列標成 is_deleted = true 但欄位值仍在，法遵上站不住。
• 第 27 條：非公務機關保有個人資料檔案者，應採行適當之安全措施。刪除流程本身就是安全維護計畫的一環。

罰則方面，依 2023 年 5 月 31 日修正公布之條文，主管機關對違反安全維護義務者得處新臺幣 2 萬元以上 200 萬元以下罰鍰，情節重大者更高；同次修法並增訂個人資料保護委員會之設置依據（資料來源：全國法規資料庫、國家發展委員會）。換句話說，「反正沒人查」這個假設的期望值已經變了。

與 GDPR 的差異：不要直接沿用歐盟 SOP

許多在台灣營運的跨國品牌直接把 GDPR 的 DSAR 流程搬過來，這會出兩個問題。第一，GDPR 第 12 條第 3 項的回應期限是「一個月」、可延長兩個月；台灣是 30 日、只能延長 30 日（依歐洲資料保護委員會 EDPB 公布之指引與全國法規資料庫條文對照）。第二，GDPR 有「被遺忘權」的明確例外清單（第 17 條第 3 項），台灣則是以「執行職務或業務所必須」這個較抽象的要件處理，舉證責任落在你身上——你必須說得出是哪一條法律、哪一份契約要求你留存。

B2B 電商的三個特殊難題

難題一：法人資料不是個資，但窗口是

《個人資料保護法》第 2 條定義的個人資料以「自然人」為限。經銷商公司的統編、公司登記地址、公司總機不是個資；但採購窗口的姓名、手機、公司信箱（[email protected] 可識別特定自然人）、LINE ID、名片照片全部是。B2B 電商的資料庫通常把兩者混在同一張 customers 表，這是刪除請求最常卡住的地方。

實務做法：在資料模型層把 account（法人）與 contact（自然人窗口）拆開，刪除請求只作用在 contact 與其衍生資料（行為事件、EDM 開信紀錄、客服對話），account 層級的交易量、信用額度、對帳單維持不動。

難題二：請求人可能已經離職

台灣 B2B 最常見的刪除請求不是「我不想被行銷」，而是「我已經離職了，請把我從你們系統移除」。此時對方已無公司信箱可驗證身分，而你手上的資料（姓名＋前公司＋手機）恰好是你唯一能核對的東西。SOP 必須明訂以最小必要資訊驗證，不可要求提供身分證正本影本作為門檻——那是額外蒐集更多敏感個資，反而擴大風險。

難題三：會計與稅務留存義務會壓過刪除請求

依《商業會計法》第 38 條，會計憑證應保存 5 年、會計帳簿及財務報表應保存 10 年；《稅捐稽徵法》亦有憑證保存規定（資料來源：全國法規資料庫）。已開立統一發票的訂單，其買受人資訊屬會計憑證的一部分，不能因刪除請求而抹除。正確的處置是：訂單與發票資料維持原狀但轉入受限存取的封存區，行銷與 CRM 層的個資硬刪除，並在回覆函中明確告知保留範圍與法律依據。

建立 SOP 前必須完成的五項盤點

1. 個資地圖（Data Map）：列出每個系統、每張表、每個欄位是否含自然人資料。最低限度要涵蓋電商平台、CRM、EDM、客服工單、資料倉儲、BI 快取、報表匯出的雲端硬碟、以及行銷團隊本機的 CSV。
2. 保存期限矩陣：每一類資料對應「法律依據＋保存年限＋到期動作」。沒有法律依據的，預設為可刪。
3. 單一受理窗口：個資法未強制設置 DPO，但實務上你需要一個對外的 privacy@ 信箱與一個內部負責人。
4. 身分驗證規則：定義三種驗證路徑（登入帳號驗證、既有信箱回覆驗證、離職者例外人工驗證）。
5. 稽核帳本：一張只寫入不更新的 dsr_ledger 表，記錄每筆請求的收件時間、驗證方式、執行時間、涵蓋系統、例外保留項目、回覆時間。這是你日後唯一能自證合規的東西。

1-- 稽核帳本：append-only，不存請求人原始個資，只存雜湊
2CREATE TABLE dsr_ledger (
3  request_id      UUID PRIMARY KEY,
4  subject_hash    CHAR(64) NOT NULL,      -- sha256(lower(email) || salt)
5  request_type    TEXT NOT NULL,          -- 'erasure' | 'access' | 'rectify'
6  received_at     TIMESTAMPTZ NOT NULL,
7  verified_at     TIMESTAMPTZ,
8  verify_method   TEXT,                   -- 'session' | 'email_loop' | 'manual'
9  deadline_at     TIMESTAMPTZ NOT NULL,   -- received_at + 30 days
10  extended_to     TIMESTAMPTZ,            -- 延長上限 +30 days
11  systems_done    JSONB DEFAULT '{}',     -- {"shopify":"2026-01-12T03:11Z", ...}
12  retained_scope  JSONB DEFAULT '[]',     -- [{"data":"invoice","law":"商業會計法§38"}]
13  responded_at    TIMESTAMPTZ
14);

刪除請求處理 SOP：七個步驟

步驟 1：受理與計時（D+0）

所有管道（客服信箱、業務轉述、網站表單、LINE 官方帳號）都必須在 24 小時內收斂成一筆 dsr_ledger 紀錄。計時起點是你「收到」的那天，不是驗證完成那天——這點很多團隊算錯，導致第 30 日才開始跑流程。

表單最少欄位：姓名、可聯絡信箱、請求類型、與貴公司的關係（採購窗口／已離職／曾註冊未下單）、希望刪除的範圍。不要在表單上要求上傳證件。

步驟 2：身分驗證（D+1 至 D+3）

三條路徑，擇一即可：

• 已登入驗證：請求人在會員後台送出，session 即為驗證。
• 信箱迴圈驗證：對系統內既有 email 寄送一次性連結（TTL 24 小時），點擊即完成。
• 人工例外驗證：離職者或信箱已失效，由法遵窗口以電話回撥既有手機號碼確認，並在帳本記錄 verify_method='manual' 與承辦人。

若 14 日內無法完成驗證，寄出一封「無法驗證身分，請補充」的通知並暫停，但不重置法定期限。

步驟 3：界定資料範圍

用一支腳本把該識別碼在所有系統的落點掃出來，避免人工漏系統。

1# dsr_discover.py — 掃描資料落點，只回傳存在與否，不落地明文個資
2import hashlib, os, json
3from connectors import shopify, hubspot, zendesk, warehouse, s3_exports
4
5SALT = os.environ["DSR_SALT"]
6
7def subject_hash(email: str) -> str:
8    return hashlib.sha256((email.strip().lower() + SALT).encode()).hexdigest()
9
10def discover(email: str) -> dict:
11    hits = {}
12    for name, conn in {
13        "shopify": shopify, "hubspot": hubspot,
14        "zendesk": zendesk, "warehouse": warehouse, "s3_exports": s3_exports,
15    }.items():
16        try:
17            hits[name] = conn.locate(email)   # -> {"found": bool, "ids": [...], "tables": [...]}
18        except Exception as e:
19            hits[name] = {"error": str(e)}    # 有錯要顯示，不可靜默跳過
20    return {"subject": subject_hash(email), "hits": hits}
21
22if __name__ == "__main__":
23    import sys
24    print(json.dumps(discover(sys.argv[1]), ensure_ascii=False, indent=2))

預期輸出：

1{
2  "subject": "9f2c...e41",
3  "hits": {
4    "shopify": {"found": true, "ids": ["gid://shopify/Customer/8123456"], "tables": ["customer","order:14"]},
5    "hubspot": {"found": true, "ids": ["301"], "tables": ["contacts","engagements"]},
6    "zendesk": {"found": true, "ids": ["5512"], "tables": ["users","tickets:3"]},
7    "warehouse": {"found": true, "tables": ["dim_contact","fct_events","mart_rfm"]},
8    "s3_exports": {"found": true, "tables": ["exports/2025-11-crm.csv"]}
9  }
10}

那個 s3_exports 命中就是實務上最常被忽略的一塊：行銷團隊半年前匯出的名單。

步驟 4：法定例外檢核

對每個命中項目問三個問題：

1. 是否有法律要求保存？（會計憑證、稅務、產品責任追溯）
2. 是否為履行既有契約所必須？（未結案的保固、應收帳款、爭議中的訂單）
3. 是否已無特定目的？（EDM 名單、網站行為事件、廢棄購物車、客服閒聊紀錄）

第 3 類一律硬刪。第 1、2 類轉匿名化封存，並在回覆函列出依據。不要把「我們內部分析需要」當成例外——第 11 條第 3 項的「業務所必須」指的是客觀必要，不是方便。

步驟 5：執行刪除

電商平台側，以 Shopify 為例，Shopify 在 2024-10 版 Admin GraphQL API 提供 customerRequestDataErasure mutation，由平台在法定保留期後排程移除顧客紀錄（資料來源：Shopify 開發者文件 Privacy law compliance）：

1mutation {
2  customerRequestDataErasure(customerId: "gid://shopify/Customer/8123456") {
3    customerId
4    userErrors { field message }
5  }
6}

CRM 側，HubSpot 提供 GDPR delete 端點，會將該 contact 永久移除並阻擋同 email 再次寫入（資料來源：HubSpot Developer Docs）：

1curl -X POST \
2  'https://api.hubapi.com/crm/v3/objects/contacts/gdpr-delete' \
3  -H "Authorization: Bearer $HUBSPOT_TOKEN" \
4  -H 'Content-Type: application/json' \
5  -d '{"objectId":"301"}'
6# 預期：204 No Content

自建資料庫側，硬刪除加上防止重新匯入的墓碑：

1BEGIN;
2
3-- 1) 行為與行銷資料：直接刪除
4DELETE FROM marketing_events  WHERE contact_id = 4471;
5DELETE FROM email_opens       WHERE contact_id = 4471;
6DELETE FROM abandoned_carts   WHERE contact_id = 4471;
7
8-- 2) 必須留存的訂單：去識別化，保留金額與統編（法人資料）
9UPDATE orders
10SET    contact_name  = '[已依個資法刪除]',
11       contact_email = NULL,
12       contact_phone = NULL,
13       ship_attention = '[已依個資法刪除]'
14WHERE  contact_id = 4471;
15
16-- 3) 聯絡人主檔：刪除
17DELETE FROM contacts WHERE id = 4471;
18
19-- 4) 墓碑：只存雜湊，避免下次同步又把人寫回來
20INSERT INTO suppression_tombstones (subject_hash, created_at, reason)
21VALUES ('9f2c...e41', now(), 'pipa_art11_erasure');
22
23COMMIT;

資料倉儲側，記得 mart 層與 BI 快取要一併重建：

1-- BigQuery：先刪事實表，再刪維度表，最後重跑下游 mart
2DELETE FROM `proj.dw.fct_events`  WHERE contact_key = '9f2c...e41';
3DELETE FROM `proj.dw.dim_contact` WHERE contact_key = '9f2c...e41';

1# dbt 重建受影響模型，確保 mart 不再殘留
2dbt run --select dim_contact+ --target prod

步驟 6：備份與第三方

備份是最常被忽略的法遵缺口。你不可能為了一筆請求去還原並改寫每一份快照，實務上可接受的處置是：

• 在還原程序中強制套用 suppression_tombstones，任何還原後的資料必須先跑一次刪除批次才能上線。
• 在回覆函中誠實說明：「備份媒介將於既定保存週期（例如 90 日）內自然輪替覆寫，期間不作任何處理利用。」
• 同步通知受委託處理者（第三方 EDM、客服外包、廣告平台的自訂受眾名單）。依個資法第 4 條，受託者之行為視同委託機關之行為，你刪了但 EDM 廠商沒刪，責任仍在你身上。

步驟 7：回覆與存證（不得逾 D+30）

回覆內容至少包含：處理結果、已刪除範圍、保留範圍與法律依據、保留資料的存取限制、未來不再行銷之保證、以及救濟管道。

範本骨架：

1敬啟者：
2
3您於 2026 年 1 月 5 日提出之個人資料刪除請求，本公司已依《個人資料保護法》第 11 條處理完畢，說明如下：
4
5一、已刪除：CRM 聯絡人主檔、電子報訂閱名單、網站行為紀錄、客服對話紀錄。
6二、依法保留：2023-2025 年度已開立統一發票之交易憑證中之買受人聯絡資訊，
7    依據《商業會計法》第 38 條會計憑證保存期間規定，保存至 2030 年 12 月 31 日；
8    該等資料已移入受限存取區，僅供稅務與稽核用途，不再作行銷或分析利用。
9三、本公司已建立排除名單，日後不會再向您寄送任何行銷訊息。
10
11如對處理結果有疑義，您得向本公司個資窗口（[email protected]）反映，
12或依法向主管機關提出申訴。

延長時，必須在 30 日內以書面告知原因，且延長不得逾 30 日。

如何驗證你真的刪乾淨了？

寫一支回歸測試，在執行後 T+1 與 T+7 各跑一次：

1# dsr_verify.py — 刪除後驗證，任何命中即 exit 1
2import sys
3from dsr_discover import discover
4
5ALLOWED = {"warehouse": [], "shopify": ["order_archive"]}  # 法定保留白名單
6
7result = discover(sys.argv[1])
8leaks = []
9for system, hit in result["hits"].items():
10    if hit.get("found"):
11        residual = [t for t in hit.get("tables", []) if t not in ALLOWED.get(system, [])]
12        if residual:
13            leaks.append((system, residual))
14
15if leaks:
16    print("FAIL 殘留：", leaks)
17    sys.exit(1)
18print("PASS 無非法殘留")

把它接進 CI 的排程任務，每週對最近 90 天的已結案請求抽樣重跑。個資法第 27 條要求的「適當安全措施」，在稽核時看的就是這種可重複、有紀錄的機制，而不是一份寫得很漂亮的政策文件。

用 LLM 加速分流，但把人留在迴路裡

B2B 電商的刪除請求通常混在一般客服信箱裡，用字也不會是「我要行使個資法第 11 條權利」，而是「麻煩把我從你們名單拿掉」「我換公司了不要再寄了」。這類分流很適合交給 LLM 做第一層判讀。

可行的設計：

1. 客服工單進來，以結構化輸出（JSON schema）讓模型判斷 is_dsr、request_type、confidence。
2. confidence >= 0.8 且為 erasure → 自動開立 dsr_ledger 紀錄並通知窗口；低於門檻 → 照常進人工佇列。
3. 模型可草擬回覆信，但保留範圍與法律依據欄位一律由人填寫，不允許模型生成法條引用。

1SCHEMA = {
2  "type": "object",
3  "properties": {
4    "is_dsr": {"type": "boolean"},
5    "request_type": {"enum": ["erasure", "access", "rectify", "opt_out", "none"]},
6    "confidence": {"type": "number"},
7    "quoted_identifier": {"type": ["string", "null"]}
8  },
9  "required": ["is_dsr", "request_type", "confidence"]
10}

重點在於：自動化縮短的是偵測與計時啟動的延遲，不是法律判斷。把模型輸出寫進帳本時，記得標註 triage_source='llm'，日後才能分開評估誤判率。

Branch8 在協助一家透過經銷商網絡銷售工業零件的 B2B 電商整併法遵流程時，採用的正是類似分層：Shopify Plus 負責前台與訂單、HubSpot 作為窗口主檔、dbt 管理倉儲層的重建順序，再以一支排程工作把 suppression_tombstones 推回各系統的匯入前置檢查。當中最花時間的往往不是寫程式，而是和財會、業務一起把「哪些資料真的必須留」逐項釐清。

跨境營運時，SOP 要怎麼一套打多國？

在台灣、香港、新加坡同時營運的品牌，不需要三套系統，但需要一套能參數化期限與例外的流程：

台灣

依《個人資料保護法》第 13 條，刪除類請求 30 日、可延長 30 日；查詢、閱覽、製給複製本為 15 日、可延長 15 日（資料來源：全國法規資料庫）。

香港

《個人資料（私隱）條例》以保障資料第 2 原則規範保留期限，資料當事人的查閱與更正請求一般須於 40 日內回覆（資料來源：香港個人資料私隱專員公署）。香港條例並無等同 GDPR 的一般性「刪除權」，但要求資料使用者在目的達成後不再保留。

新加坡

《個人資料保護法令》（PDPA）下，個人可撤回同意，組織須停止蒐集、使用或披露，並依 Retention Limitation Obligation 停止保留不再有商業或法律目的之資料（資料來源：新加坡 Personal Data Protection Commission）。

歐盟

GDPR 第 17 條刪除權、第 12 條第 3 項一個月回應期限、可延長兩個月（資料來源：歐洲資料保護委員會 EDPB）。

實作建議：把期限做成設定檔而不是寫死在程式裡。

1jurisdictions:
2  TW: { erasure_days: 30, extension_days: 30, access_days: 15, basis: "PIPA Art.11/13" }
3  HK: { access_days: 40, extension_days: 0,  basis: "PDPO DPP2/DPP6" }
4  SG: { withdrawal_days: 30, extension_days: 0, basis: "PDPA Retention Limitation" }
5  EU: { erasure_days: 30, extension_days: 60, basis: "GDPR Art.17/12(3)" }
6default_policy: strictest   # 跨境個案一律採最嚴期限

對美國、英國、歐盟總部型客戶而言，把刪除請求的執行放在亞洲團隊有一個實際好處：亞洲時區的白天正好覆蓋歐洲清晨與美東深夜，30 日的法定期限在跨時區交接下幾乎不會因為「等總部回覆」而燒掉一週。

常見錯誤與排錯

錯誤一：軟刪除當成刪除。 施行細則第 6 條要求資料「消失」。deleted_at 加時間戳但欄位值仍在，等於沒刪。做法：軟刪除只能作為執行中的中繼狀態，排程作業必須在 T+7 內轉為硬刪除或覆寫。

錯誤二：刪了主檔，忘了衍生資料。 客服附件、EDM 平台的自訂受眾、廣告平台上傳的雜湊名單、BI 匯出的 Google Sheet。用 dsr_discover.py 的系統清單當作唯一真實來源，新增系統時同步新增 connector，否則掃不到。

錯誤三：刪完隔天又被同步回來。 這是 ETL 從舊備份或第三方回灌造成的。解法就是前述的 suppression_tombstones 前置檢查：任何 upsert 前先比對雜湊，命中則跳過並記錄告警。

錯誤四：把法人資料一併刪掉。 刪掉了經銷商的統編與交易紀錄，導致帳務對不上。解法：資料模型先拆 account / contact，刪除作業只以 contact_id 為入口。

錯誤五：計時起點算錯。 期限從收件日起算，不是驗證完成日。在受理表單自動寫入 received_at 與 deadline_at，並設定 D+20 的自動提醒。

錯誤六：回覆信裡承諾「已全數刪除」，但備份仍有。 這在事後遭申訴時會變成不實陳述。誠實說明備份輪替週期，比事後解釋安全得多。

排錯提示：如果 dsr_verify.py 在 T+7 仍回報 warehouse 命中，通常不是刪除沒執行，而是 dbt 的 incremental model 沒有重跑 full refresh。以 dbt run --select dim_contact+ --full-refresh 重建一次即可確認。

把 SOP 變成常態機制

刪除請求的合規成本，八成來自沒有資料地圖、沒有墓碑機制、沒有稽核帳本——每一筆請求都變成一次人工考古。把這三件事建起來之後，單筆請求的處理會從跨部門的協調專案，收斂成一支腳本加一次人工複核。

如果你正在台灣或跨亞太多市場經營 B2B 電商，需要把個資請求處理、資料地圖與跨系統刪除鏈實際接起來，Branch8 在香港、新加坡、台灣、澳洲等地的團隊長期處理這類跨境電商與資料架構專案，歡迎與我們聊聊你目前的系統落點與法遵缺口。

Sources

• 全國法規資料庫 — 個人資料保護法
• 全國法規資料庫 — 法規檢索首頁
• 國家發展委員會
• Shopify Developers — Privacy law compliance
• HubSpot Developers — CRM Contacts API
• European Data Protection Board
• Personal Data Protection Commission Singapore
• 香港個人資料私隱專員公署 PCPD