香港電商品牌 GDPR 跨境數據傳輸歐盟客戶合規指南

香港電商只要針對歐盟消費者銷售，即使沒有歐盟實體，也受 GDPR 第 3(2) 條約束。香港不在歐盟適足性名單內，因此把歐盟客戶數據傳回亞洲，必須簽署 2021 版標準合約條款（SCC）、完成轉移影響評估（TIA），並指定歐盟代表。

香港電商賣歐盟客戶，GDPR 真的管得到你嗎？

管得到。GDPR 第 3(2) 條採用「目標導向測試」（targeting test）：只要你向歐盟境內的個人提供商品或服務，或監控他們在歐盟境內的行為，不論你公司註冊在中環、新加坡還是台北，條例都適用。

歐洲數據保護委員會（EDPB）在《Guidelines 3/2018 on the territorial scope of the GDPR》中明確指出，判斷是否「針對」歐盟消費者，不看網站是否可被存取，而看一系列具體指標：是否使用歐盟成員國語言、是否以歐元標價、是否提供歐盟境內配送選項、是否投放以歐盟國家為定向的廣告、是否使用 .de / .fr 等頂級域名。

換句話說，一個香港 DTC 品牌如果在 Shopify 後台開了「EUR 貨幣 + 德國配送區 + 德文版店面」，三個條件同時成立，幾乎無法主張自己不在管轄範圍內。

風險不是理論性的。根據 CMS Law 維護的 GDPR Enforcement Tracker，自 2018 年執法以來公開累計罰款已超過 50 億歐元；其中愛爾蘭數據保護委員會（DPC）在 2023 年 5 月對 Meta 開出 12 億歐元罰單，理由正是未合規的歐盟—美國數據傳輸。GDPR 第 83 條規定的上限是全球年營業額 4% 或 2,000 萬歐元，取其高者。

四個快速自我測試

1. 你的店面是否提供歐元或任何歐盟成員國貨幣結帳？
2. 你的物流選項是否包含歐盟地址？
3. 你是否在 Meta、Google 或 TikTok 上對歐盟國家做地理定向投放？
4. 你是否用 cookie、pixel、session replay 工具追蹤歐盟訪客行為？

任何一項為「是」，就應假設 GDPR 適用，並據此設計數據流程。第 4 項尤其容易被忽略——即使你不出貨到歐盟，只要安裝了 Meta Pixel 並對歐盟訪客收集行為數據，就構成第 3(2)(b) 條的「行為監控」。

為什麼香港不在歐盟的適足性白名單上？

歐盟執委會（European Commission）迄今通過的適足性決定（adequacy decision）約 15 個司法管轄區，亞太區只有日本（2019）、韓國（2021 年 12 月）和紐西蘭（2012）在列。香港、新加坡、台灣、馬來西亞、越南都不在名單上。

對香港而言，核心結構性問題是《個人資料（私隱）條例》（PDPO）第 33 條——規管個人資料跨境轉移的條文——自 1995 年立法至今仍未生效。香港個人資料私隱專員公署（PCPD）在 2014 年發出《跨境資料轉移指引》並在 2022 年發布建議範本條款，但那是自願性質，不是法定要求。歐盟評估適足性時看的是「實質等同」的法律保護水平，自願指引難以滿足。

實務結論很簡單：香港公司把歐盟客戶數據傳回香港、新加坡或任何非適足地區，都屬於 GDPR 第五章定義的「第三國傳輸」，必須有合法傳輸工具。

標準合約條款（SCC）模組怎麼選？

歐盟執委會於 2021 年 6 月 4 日通過實施決定 2021/914，取代 2010 年舊版 SCC。新版採模組化設計，你必須選對模組，簽錯等同沒簽。

Module 1：控制者對控制者（C2C）

香港母公司與歐盟子公司各自獨立決定處理目的時適用。例如歐盟分公司自行經營會員計劃，而香港總部也用同一批數據做全球 CRM 分析。

Module 2：控制者對處理者（C2P）

電商最常用的模組。 你（香港品牌，控制者）把歐盟客戶數據交給亞洲的客服外包商、履約中心或數據分析團隊（處理者）時使用。

Module 3：處理者對處理者（P2P）

你是歐盟品牌的處理者，再把工作轉包給越南或菲律賓的次處理者時使用。做白牌營運或代營運的香港公司經常漏掉這一層。

Module 4：處理者對控制者（P2C）

較少見，適用於歐盟處理者把數據回傳給第三國控制者。

SCC 的關鍵限制：它不是簽完就了事。Schrems II 判決（CJEU C-311/18，2020 年 7 月 16 日）要求資料輸出者在依賴 SCC 前，必須評估接收國法律是否會削弱條款的保護效力。這就是 TIA。

轉移影響評估（TIA）實際要寫什麼？

EDPB《Recommendations 01/2020》列出六步法。對香港電商而言，一份能通過審查的 TIA 至少要涵蓋：

1. 完整傳輸地圖——誰傳給誰、傳什麼欄位、用什麼傳輸工具、頻率、儲存位置。
2. 傳輸工具確認——SCC 版本、模組、簽署日期。
3. 目的地法律評估——香港的《截取通訊及監察條例》、《國家安全法》第 43 條實施細則下的數據索取權限，以及電訊商協助義務。這一段必須誠實寫，寫得含糊反而是風險。
4. 補充措施——技術、合約、組織三類。
5. 程序步驟——誰批准、多久複審。
6. 持續監控——法律變動時的重新評估觸發條件。

實務上，第 3 點是香港公司最難處理的部分。可行的對策不是淡化，而是用技術措施讓「即使被索取也無法還原」——這也是 EDPB 認為最有效的補充措施類別。

技術補充措施：讓數據在傳輸前就失去可識別性

EDPB 的 Use Case 之一是「傳輸前已以強加密保護，且金鑰僅由歐盟境內的輸出者持有」。對電商技術棧來說，有幾個可落地的模式。

歐盟區域化儲存 + 代碼化回傳

把歐盟客戶的 PII 留在法蘭克福或都柏林區域，只讓亞洲團隊存取經代碼化（pseudonymised）的分析數據。

1# Terraform：歐盟客戶資料只落在 eu-central-1
2resource "aws_s3_bucket" "eu_customer_pii" {
3  bucket = "brand-eu-pii-prod"
4  tags = { DataClass = "PII-EU", TransferTool = "none" }
5}
6
7resource "aws_s3_bucket_server_side_encryption_configuration" "eu_pii" {
8  bucket = aws_s3_bucket.eu_customer_pii.id
9  rule {
10    apply_server_side_encryption_by_default {
11      sse_algorithm     = "aws:kms"
12      kms_master_key_id = aws_kms_key.eu_only.arn  # 金鑰政策限定 eu-central-1
13    }
14  }
15}

分析層只看雜湊後的識別碼

1-- 同步到亞太分析倉庫前先代碼化
2CREATE OR REPLACE VIEW analytics.eu_orders_pseudo AS
3SELECT
4  encode(digest(customer_email || :pepper, 'sha256'), 'hex') AS customer_key,
5  order_id,
6  country_code,
7  order_total_eur,
8  created_at
9FROM raw.eu_orders;
10-- pepper 存於歐盟 KMS，亞太團隊無存取權

這個設計的取捨要說清楚：代碼化之後，亞洲團隊無法直接做個人化再行銷，也無法在 CRM 中查單一客戶。你換到的是大幅縮小的傳輸範圍與更容易通過的 TIA。對多數品牌來說，個人化活動在歐盟區域內執行、全球報表用代碼化數據，是可接受的平衡。

Shopify、自建站與 CDP 的同意管理怎麼配置？

GDPR 第 6 條要求每一項處理都有法律依據。行銷 cookie 與廣告 pixel 在 ePrivacy Directive 下需要事前同意——先載入後詢問是違規的。

Shopify 提供 Customer Privacy API，可在同意前阻擋追蹤腳本：

1// 等待同意後才初始化行銷像素
2window.Shopify.loadFeatures(
3  [{ name: 'consent-tracking-api', version: '0.1' }],
4  (error) => {
5    if (error) return;
6    const consent = window.Shopify.customerPrivacy.currentVisitorConsent();
7    if (consent.marketing === 'yes') {
8      initMetaPixel();
9      initTikTokPixel();
10    }
11  }
12);
13
14// 使用者更新選擇時同步到 Shopify
15window.Shopify.customerPrivacy.setTrackingConsent(
16  { marketing: false, analytics: true, preferences: true, sale_of_data: false },
17  () => console.log('consent updated')
18);

若使用 Google 生態工具，需同時實作 Consent Mode v2：

1gtag('consent', 'default', {
2  ad_storage: 'denied',
3  ad_user_data: 'denied',
4  ad_personalization: 'denied',
5  analytics_storage: 'denied',
6  region: ['AT','BE','BG','HR','CY','CZ','DK','EE','FI','FR','DE','GR','HU','IE','IT','LV','LT','LU','MT','NL','PL','PT','RO','SK','SI','ES','SE','IS','LI','NO','GB'],
7  wait_for_update: 500
8});

注意 region 陣列需包含 EEA 三國與英國——英國脫歐後適用 UK GDPR，規則幾乎一致但傳輸工具要用 UK International Data Transfer Agreement（IDTA）或 UK Addendum，英國資訊專員辦公室（ICO）有提供範本。

歐盟代表、隱私政策與處理紀錄

第 27 條：歐盟代表

沒有歐盟據點但受 GDPR 管轄的香港公司，必須以書面指定一位設於歐盟境內的代表，地點通常選在客戶最集中的成員國。代表的聯絡方式要公開在隱私政策與網站頁尾。例外僅限於「偶發性、不涉及大規模特殊類別數據且風險低」的處理——持續經營的電商店面不符合這個例外。

第 30 條：處理活動紀錄（RoPA）

250 人以下企業原則上豁免，但只要處理不是偶發性的（電商訂單顯然不是），豁免就不適用。RoPA 是監管機關第一個索取的文件。

1# ropa/eu-dtc-store.yaml — 版本控管在 Git，變更可追溯
2processing_activity: EU DTC 訂單履約
3controller: 香港營運實體
4purposes: [訂單履約, 付款處理, 客服, 售後保固]
5legal_basis: Art. 6(1)(b) 契約履行
6data_subjects: [歐盟消費者]
7data_categories: [姓名, 電郵, 配送地址, 電話, 訂單紀錄]
8recipients:
9  - name: 第三方支付服務商（歐盟境內）
10    role: processor
11  - name: 亞太客服團隊
12    role: processor
13    transfer_tool: SCC 2021/914 Module 2
14    tia_ref: TIA-2026-003
15retention: 訂單完成後 7 年（稅務要求），行銷同意記錄 3 年

把 RoPA 放進 Git 而不是試算表，是我們反覆建議的做法：每次改動都有 commit 記錄，審計時能證明治理是持續的而非事後補做。

72 小時外洩通報與 DSAR 的作業現實

GDPR 第 33 條要求控制者在「知悉」個資外洩後 72 小時內通報主管機關；第 12(3) 條要求在收到資料主體請求後一個月內回覆，複雜案件可延長兩個月但須在首月內告知。

香港團隊的實際難點是時差。倫敦或柏林的客戶在歐洲時間下午提出刪除請求，香港團隊隔天早上才看到，72 小時的窗口已經消耗掉三分之一。這正是亞太多市場營運的價值所在——香港、新加坡、台北的工作時間覆蓋歐洲早晨，澳洲團隊覆蓋歐洲深夜，實際上可以做到接近全天候的事件回應。

可操作的 DSAR SLA 設計：

1. Day 0–1：自動確認收件，驗證身分（不要用電郵地址本身作為唯一驗證）。
2. Day 2–5：跨系統檢索——Shopify、Klaviyo、客服工單、數據倉庫、備份。
3. Day 6–20：審核輸出，遮蔽第三方個資。
4. Day 21–30：交付並記錄完成時間。

備份是最常被漏掉的一環。刪除請求若未涵蓋快照與離線備份，技術上就沒有完成。合理做法是在隱私政策中說明備份輪替週期，並確保刪除標記會在備份還原時重新套用。

AI 與自動化如何把合規作業規模化？

合規最大的成本不是法律意見，是持續性的文書與檢索工作。2026 年的實務是用 LLM 把這些工作壓縮。

可以交給 LLM 的：

• 從 Git diff 自動草擬 RoPA 更新摘要
• 掃描新安裝的 Shopify app，比對其隱私政策，標記新增的次處理者
• 把 DSAR 跨系統檢索結果彙整成結構化輸出草稿
• 用向量檢索在內部政策庫中回答員工的「這個數據能不能傳回香港」問題

1# CI 檢查：偵測新增的第三方腳本網域，未登記者阻擋合併
2npx @branch8/script-audit scan ./theme \
3  --allowlist compliance/subprocessors.yaml \
4  --fail-on-unknown

不應交給 LLM 的： TIA 的法律結論、外洩是否需要通報的判斷、SCC 模組的最終選擇。這些是需要具名問責的決定，模型輸出只能作為初稿。

我們曾協助一家經營多個歐洲市場的亞太消費品牌，把 RoPA 與次處理者清單從 Google Sheets 遷到 Git 倉庫，再用 GitHub Actions 搭配 LLM 在每次主題或 app 變更時產生合規影響摘要，交由法務覆核。機制的價值在於變更不再沉默發生——至於它省下多少工時，取決於各家的基準，我們不會替你假設。

把香港與新加坡當成跨境合規營運樞紐

對美國、英國、歐盟品牌而言，亞洲不只是生產與履約基地，也可以是合規營運基地。理由有三：

• 時區覆蓋：香港與新加坡的工作日覆蓋歐洲早上與美東深夜，配合澳洲團隊可形成三段式輪值，對 72 小時通報與一個月 DSAR 時限是實質優勢。
• 多法域熟悉度：同一支團隊同時處理 GDPR、UK GDPR、香港 PDPO、新加坡 PDPA、澳洲 Privacy Act、中國大陸 PIPL 與台灣個資法。歐盟品牌若要進軍亞洲，這種跨法域視角比單一市場的法務更實用。
• 語言與文化流暢度：日文、韓文、繁簡中文、英文、越南文的客服與 DSAR 處理能力，在同一個營運中心內解決。

要注意的取捨：把歐盟客戶數據的操作權交給亞洲團隊，必然擴大傳輸範圍。務實做法是分層 ——第一線客服在歐盟區域系統內操作（存取不等於傳輸，但需在 TIA 中記錄遠端存取），深度分析與工程工作只接觸代碼化數據。

90 天落地路線圖

第 1–30 天：盤點

1. 完成數據流地圖，標記所有離開 EEA 的流向。
2. 列出所有處理者與次處理者，包含 Shopify app 與廣告平台。
3. 確認每一條傳輸是否已有有效的 2021 版 SCC。

第 31–60 天：補齊文件

4. 簽署或更新 SCC，選對模組。
5. 撰寫 TIA，誠實評估香港法律環境並列出補充措施。
6. 指定第 27 條歐盟代表並公開聯絡方式。
7. 建立 Git 版本控管的 RoPA。

第 61–90 天：技術與流程

8. 部署事前同意的 CMP，實作 Consent Mode v2 與 Shopify Customer Privacy API。
9. 設定歐盟區域儲存與代碼化管線。
10. 建立 DSAR 工作流與 72 小時外洩通報演練（實際跑一次桌面演習）。

合規不是一次性專案。SCC 需在法律環境變動時重評，次處理者清單會隨每個新 app 改變，而歐盟執委會的適足性決定每四年複審一次。把這些設計成持續運行的流程，比每年突擊補件便宜得多。

Branch8 以香港為總部，在新加坡、台北、胡志明市、吉隆坡、雅加達、馬尼拉與澳洲設有交付團隊，為跨境電商品牌建置符合 GDPR 的數據架構、同意管理與 DSAR 營運流程。若你正在為歐盟市場的數據傳輸設計架構，或需要一支橫跨多法域的技術與營運團隊，歡迎與我們談談你的具體流向與時程。

Sources

• European Commission — Adequacy decisions
• European Commission — Standard Contractual Clauses (Implementing Decision 2021/914)
• European Data Protection Board — Guidelines, Recommendations, Best Practices
• GDPR-info.eu — Full text of the General Data Protection Regulation
• Hong Kong PCPD — Personal Data (Privacy) Ordinance and guidance
• UK ICO — International data transfer agreement and guidance
• CMS — GDPR Enforcement Tracker
• Shopify — Customer Privacy API documentation