Branch8

台灣個資法委外處理個資合約條款教學:逐條撰寫實作

Matt Li
October 26, 2026
14 mins read
台灣個資法委外處理個資合約條款教學:逐條撰寫實作

Key Takeaways

  • 個資法施行細則第 8 條列出委外監督的法定應載事項,缺一不可
  • 採「主約 + DPA 附件 + 技術措施附件」三層結構,便於跨法域重複使用
  • 複委託、事故通報、稽核權、終止後銷毀是最常被遺漏的四條
  • LLM 供應商屬委外處理,須禁止訓練用途並列入複委託清單
  • 用 YAML registry 加 CI 腳本,把合規狀態變成可自動檢核的訊號

台灣《個人資料保護法》第 4 條與施行細則第 8 條規定,委託他人蒐集、處理或利用個人資料時,委託機關必須對受託者進行適當監督,並以書面明定監督範圍、資安措施、轉委託限制、事故通報與契約終止後的資料返還或銷毀。本文逐條拆解合約條款怎麼寫,並附上可直接套用的中文條文範本、技術附件(Annex)與稽核檢核腳本。

為什麼委外條款是台灣個資法最常被忽略的風險點?

多數台灣企業以為個資合規只要寫好隱私權政策、放上 Cookie 同意條就完成了。實際上,真正會在主管機關檢查時被挑出問題的,往往是「委外」這一塊:把電商訂單資料丟給第三方物流、把會員名單匯進海外行銷自動化平台、把客服對話丟給 LLM 供應商做摘要。

依據個資法施行細則第 8 條,委託機關對受託者的監督事項至少應包含:蒐集處理利用的範圍與方式、採取的安全管理措施、受託者的複委託(轉委託)限制、事故通報義務、契約終止後資料的返還或刪除,以及委託機關的稽核權。這些不是「建議」,是法定應監督事項。

2023 年個資法修正新增主管機關為「個人資料保護委員會」(個資會),並提高行政罰鍰上限至新臺幣 1,500 萬元(依國家發展委員會公布之修正條文)。對跨境營運的公司來說,這代表台灣的委外風險不再是可以放到最後處理的項目。

另一個現實面:台灣的個資保護機制至今尚未取得歐盟 GDPR 適足性認定(依歐盟執委會公布之適足性決定清單,目前僅日本、韓國、英國等少數法域在列)。因此若你的資料流同時涉及歐盟,台灣端的委外合約還得額外搭配 GDPR 第 28 條處理者條款與標準契約條款(SCCs)。一份合約要同時扛兩套法規,結構必須從一開始就設計好。

動手前要先備齊的四項前置作業

寫條款之前,缺少這四樣東西會導致條文寫得漂亮但無法執行。

1. 完整的資料流清單(Data Flow Inventory)

列出每一個會接觸個資的外部廠商、資料欄位、傳輸方式、儲存地點。建議用 YAML 管理並納入版本控制:

1# data-flows/vendor-registry.yaml
2vendors:
3 - vendor_id: LOG-001
4 name_internal: "第三方倉儲物流商 A"
5 role: "受託者" # 受託者 / 共同控制
6 purpose: "出貨配送與退貨處理"
7 data_subjects: ["消費者"]
8 data_fields:
9 - 姓名
10 - 行動電話
11 - 配送地址
12 special_category: false
13 transfer_method: "REST API over TLS 1.3"
14 storage_region: "TW"
15 sub_processors: ["區域配送車隊 A1"]
16 retention_days: 180
17 contract_ref: "CT-2026-014"
18 - vendor_id: MKT-003
19 name_internal: "行銷自動化 SaaS"
20 role: "受託者"
21 purpose: "EDM 發送與開信追蹤"
22 data_fields: ["Email", "姓名", "開信紀錄"]
23 storage_region: "US-EAST" # 觸發國際傳輸條款
24 sub_processors: ["AWS", "SendGrid"]
25 retention_days: 730
26 contract_ref: "CT-2025-089"

2. 判斷角色:受託者還是另一個蒐集者

這一步決定合約型態。若廠商只能依你的指示處理資料、不得為自身目的利用,屬於受託者,適用個資法第 4 條(視同委託機關之行為)。若廠商自行決定利用目的(例如廣告平台用你的名單做 lookalike 建模),它就是獨立的蒐集者,你需要的是資料共享/提供條款與告知同意基礎,而非單純的委外監督條款。

3. 既有合約盤點

把現行 MSA、SOW、NDA 翻出來,確認個資條款是放在主約、附件還是完全沒有。多數情況是散落各處且互相矛盾。

4. 內部核准路徑

法務、資安、業務單位誰簽核、誰有權同意轉委託,先定義清楚,否則條款中的「經委託機關事前書面同意」會變成無人執行的空話。

Ready to Transform Your Ecommerce Operations?

Branch8 specializes in ecommerce platform implementation and AI-powered automation solutions. Contact us today to discuss your ecommerce automation strategy.

合約架構怎麼切?主約 + 個資處理附件

不要把個資條款塞進主約正文。實務上建議三層結構:

主約(MSA / 服務合約)

只放一句援引條款:「雙方就個人資料之蒐集、處理及利用,依本合約附件一『個人資料委外處理條款』辦理;附件一與本約本文牴觸者,以附件一為準。」

附件一:個人資料委外處理條款(DPA)

法律條文本體,對應個資法施行細則第 8 條各款。這份文件應設計為可重複使用的標準範本。

附件二:技術與組織措施(Technical & Organisational Measures, TOMs)

具體的加密演算法、存取控制、日誌保存期間、弱點掃描頻率。這份要能隨技術演進修訂,不需重談主約。

這種切法的好處是:當你在台灣、新加坡、馬來西亞同時使用同一家 SaaS 供應商時,主約談一次,附件一依各法域(台灣個資法、新加坡 PDPA、馬來西亞 PDPA 2010)產出在地版本,附件二共用一份。

逐條撰寫:八個必備條款與範本文字

以下條文可直接作為起草基礎,但務必經台灣執業律師審閱後使用。

條款一:處理範圍與指示拘束

1第一條(委託範圍與指示)
21.1 受託者僅得於甲方(委託機關)書面指示之範圍內,為本附件附表一所列
3 之特定目的,蒐集、處理或利用個人資料,不得為自身或第三人之目的
4 利用之。
51.2 受託者認甲方之指示違反個人資料保護法或其他法令者,應立即以書面
6 通知甲方,並於甲方確認前暫停相關處理行為。
71.3 本條所稱書面,包含經雙方指定窗口之電子郵件及工單系統紀錄。

第 1.3 項很重要。沒有這句,日常營運中透過 Jira 或 Slack 下達的處理指示在法律上的地位會變得模糊。

條款二:安全管理措施

不要在條文中寫死技術規格,改為援引附件二:

1第二條(安全管理措施)
22.1 受託者應採取附件二所列之技術與組織措施,其水準不得低於個人資料
3 保護法施行細則第十二條所定之標準。
42.2 附件二之修訂,得經雙方書面同意後為之,無須變更本合約其他條款。
5 受託者單方降低安全措施水準者,視為重大違約。

附件二的實際內容建議以可驗證的形式撰寫:

1【附件二 技術與組織措施】
2A. 傳輸加密:TLS 1.2 以上,禁用 SSLv3、TLS 1.0/1.1。
3B. 儲存加密:靜態資料採 AES-256 加密;金鑰以 KMS 管理,
4 金鑰輪替週期不超過 365 日。
5C. 存取控制:最小權限原則,採角色為基礎之存取控制(RBAC);
6 具個資存取權限之帳號應啟用多因素驗證。
7D. 日誌:個資存取紀錄保存不少於 180 日,且日誌本身不得含
8 未遮罩之個人資料。
9E. 弱點管理:每季執行一次弱點掃描,高風險(CVSS ≥ 7.0)
10 項目應於 30 日內修補。
11F. 人員:接觸個資之人員應簽署保密切結書,並每年接受個資
12 教育訓練不少於 2 小時。

條款三:轉委託(複委託)限制

1第三條(複委託)
23.1 受託者非經甲方事前書面同意,不得將本委託事項之全部或一部
3 複委託第三人。
43.2 甲方同意之複委託對象,列於附表二。受託者擬新增或變更複委託
5 對象者,應於預定生效日前三十(30)日以書面通知甲方;甲方得
6 於十四(14)日內以正當理由拒絕。
73.3 受託者應與複委託對象簽訂不低於本附件義務水準之書面契約,並
8 就複委託對象之行為對甲方負全部責任。

第 3.2 項的「事前通知 + 異議期」是處理 SaaS 供應商的現實折衷。大型雲端供應商不會接受逐一事前同意,但會接受提前公告與異議機制。

條款四:事故通報

1第四條(個人資料事故通報)
24.1 受託者知悉個人資料遭竊取、竄改、毀損、滅失或洩漏(以下稱
3 「個資事故」)時,應於知悉後二十四(24)小時內以電話及電子
4 郵件通知甲方指定窗口。
54.2 受託者應於知悉後七十二(72)小時內提交初步書面報告,載明:
6 (a) 事故發生時間與發現時間
7 (b) 受影響之個人資料種類與筆數(含估計值)
8 (c) 可能造成之影響
9 (d) 已採取及擬採取之應變措施
104.3 受託者應配合甲方依個人資料保護法第十二條對當事人為通知,
11 及依主管機關要求提交之說明,所生費用由受託者負擔。

24 小時是給委託機關留出反應時間的內部設計。個資法第 12 條要求查明後以適當方式通知當事人,並未明定小時數,但若你的資料流同時涉及歐盟,GDPR 第 33 條的 72 小時監管機關通報義務會往前壓縮受託者的時程,因此受託者端必須更短。

條款五:稽核權

1第五條(稽核)
25.1 甲方或其委任之第三方稽核人員,得於事前十(10)個工作日書面
3 通知後,於正常營業時間內進行書面稽核或實地稽核,每年以一次
4 為限。發生個資事故或主管機關要求時,不受次數及預告期間限制。
55.2 受託者得以最近十二個月內之 ISO/IEC 27001 驗證證書、SOC 2
6 Type II 報告或等同之第三方稽核報告,替代實地稽核;惟甲方認
7 該報告未涵蓋本委託事項者,仍得要求實地稽核。

5.2 的替代機制是讓這份合約在面對國際 SaaS 時仍可簽成的關鍵。

條款六:國際傳輸

1第六條(國際傳輸)
26.1 受託者將個人資料傳輸至中華民國領域外者,應事前取得甲方書面
3 同意,並告知接收國家或地區、接收者及其安全維護措施。
46.2 受託者應確保該傳輸符合個人資料保護法第二十一條及主管機關就
5 特定行業所為之限制令。
66.3 若受託者同時處理受歐盟一般資料保護規則(GDPR)規範之個人資料,
7 雙方應另行簽署歐盟標準契約條款(SCCs)作為本附件之附件三,
8 其效力優先於本附件相牴觸之約定。

個資法第 21 條授權中央目的事業主管機關在特定情形下限制國際傳輸(例如涉及重大國家利益、接收國法令對個資保護不足)。歷史上金管會、通傳會等機關確實對特定行業發布過限制令,因此條文要保留可因應的彈性。

條款七:終止後資料處置

1第七條(契約終止後之處置)
27.1 本合約終止或屆期後三十(30)日內,受託者應依甲方指示返還或
3 刪除全部個人資料及其備份,並出具經權責主管簽署之銷毀證明書。
47.2 受託者依法令須保存者,應以書面載明法令依據及保存期限,並於
5 保存期間內停止一切其他處理行為。
67.3 備份媒體之刪除,應符合 NIST SP 800-88 之清除(Clear)或
7 清洗(Purge)標準。

條款八:責任與違約

1第八條(責任)
28.1 受託者違反本附件義務致甲方受有損害(含對當事人之損害賠償、
3 主管機關罰鍰、法律費用及事故應變費用)者,應負賠償責任。
48.2 本附件所生之賠償責任,不適用主約所定之責任上限。

第 8.2 項通常是談判中最硬的一條。實務上的折衷是設定一個高於主約上限的個資專屬上限(例如年度合約金額的 2 至 3 倍),而非完全不設限。

Ready to Transform Your Ecommerce Operations?

Branch8 specializes in ecommerce platform implementation and AI-powered automation solutions. Contact us today to discuss your ecommerce automation strategy.

把 AI 與 LLM 供應商納入條款的三個調整

2026 年的委外場景已經不只是物流和客服外包。把客服逐字稿丟給 LLM 做摘要、用生成式模型產生商品描述、讓 AI agent 讀取 CRM 資料,這些都構成個資委外處理。傳統條款有三個漏洞:

  1. 訓練資料使用。必須明文禁止受託者以你的個資訓練或微調其通用模型。範例文字:「受託者不得以本委託事項所取得之個人資料,用於訓練、微調或改善其對甲方以外客戶提供之任何模型或服務。」
  2. 模型供應商即複委託對象。若 SaaS 廠商背後串接 OpenAI、Anthropic 或 Google 的 API,這些都應列入附表二的複委託清單。
  3. 資料留存期間。多數 LLM API 預設有數十天的濫用監控留存。若需要零留存,必須在合約中明確要求並確認供應商的企業方案是否支援。

實作上,建議在送入模型前先做欄位遮罩。以下是 Python 的最小範例:

1import re
2
3PATTERNS = {
4 "TW_ID": re.compile(r"\b[A-Z][12]\d{8}\b"), # 身分證字號
5 "TW_MOBILE": re.compile(r"\b09\d{2}-?\d{3}-?\d{3}\b"),
6 "EMAIL": re.compile(r"\b[\w.+-]+@[\w-]+\.[\w.]+\b"),
7}
8
9def redact(text: str) -> tuple[str, dict]:
10 mapping = {}
11 for label, pattern in PATTERNS.items():
12 for i, m in enumerate(pattern.findall(text)):
13 token = f"[{label}_{i}]"
14 mapping[token] = m
15 text = text.replace(m, token)
16 return text, mapping
17
18sample = "客戶 A123456789 來電,手機 0912-345-678,信箱 [email protected]"
19redacted, mapping = redact(sample)
20print(redacted)
21# 客戶 [TW_ID_0] 來電,手機 [TW_MOBILE_0],信箱 [EMAIL_0]

遮罩不是萬靈丹——姓名、地址、組合性識別資訊仍可能外洩,所以合約條款與技術控制必須並行,不能二擇一。

用腳本管理合約到期與稽核週期

條款簽完只是起點。真正會出事的是三年後沒人記得某家廠商的 DPA 從未更新。把 vendor registry 接上檢核腳本,排進 CI:

1# scripts/check_vendor_compliance.py
2import sys, yaml
3from datetime import date, timedelta
4
5REQUIRED = ["role", "purpose", "data_fields", "storage_region",
6 "retention_days", "contract_ref", "dpa_signed_on",
7 "last_audit_on"]
8
9def main(path: str) -> int:
10 data = yaml.safe_load(open(path, encoding="utf-8"))
11 today, issues = date.today(), []
12
13 for v in data["vendors"]:
14 vid = v.get("vendor_id", "UNKNOWN")
15 for field in REQUIRED:
16 if not v.get(field):
17 issues.append(f"{vid}: 缺少必填欄位 {field}")
18 audit = v.get("last_audit_on")
19 if audit and (today - audit) > timedelta(days=365):
20 issues.append(f"{vid}: 稽核逾期,上次稽核 {audit}")
21 if v.get("storage_region", "TW") != "TW" and not v.get("cross_border_approval"):
22 issues.append(f"{vid}: 境外儲存但無國際傳輸核准紀錄")
23 if v.get("sub_processors") and not v.get("sub_processor_approved_on"):
24 issues.append(f"{vid}: 複委託對象未經核准")
25
26 for i in issues:
27 print(f"[FAIL] {i}")
28 print(f"\n檢查 {len(data['vendors'])} 家廠商,發現 {len(issues)} 項問題")
29 return 1 if issues else 0
30
31if __name__ == "__main__":
32 sys.exit(main(sys.argv[1]))

預期輸出:

1[FAIL] MKT-003: 境外儲存但無國際傳輸核准紀錄
2[FAIL] MKT-003: 複委託對象未經核准
3
4檢查 2 家廠商,發現 2 項問題

接上 GitHub Actions,每月排程執行:

1# .github/workflows/vendor-compliance.yml
2name: vendor-compliance
3on:
4 schedule:
5 - cron: "0 1 1 * *" # 每月 1 日 UTC 01:00
6 workflow_dispatch:
7jobs:
8 check:
9 runs-on: ubuntu-latest
10 steps:
11 - uses: actions/checkout@v4
12 - uses: actions/setup-python@v5
13 with:
14 python-version: "3.12"
15 - run: pip install pyyaml
16 - run: python scripts/check_vendor_compliance.py data-flows/vendor-registry.yaml

這個做法的價值不在腳本本身有多聰明,而在於把合規狀態變成一個會在 pipeline 裡紅掉的訊號,而不是一份沒人開啟的 Excel。

Ready to Transform Your Ecommerce Operations?

Branch8 specializes in ecommerce platform implementation and AI-powered automation solutions. Contact us today to discuss your ecommerce automation strategy.

跨境營運:一份合約如何同時對應台灣、新加坡與歐盟?

對於以亞太為營運基地的企業——例如在台灣設技術團隊、在新加坡設區域總部、客戶分布於美國與歐洲——委外合約的真正挑戰是法域疊加。

共通層可以統一

安全管理措施(附件二)、事故通報流程、稽核機制、終止後處置,這些在台灣個資法、新加坡 PDPA、GDPR 第 28 條之間的要求高度重疊,寫一份最嚴標準即可通用。

法域層必須分開

  • 台灣:施行細則第 8 條的監督事項清單、第 21 條的國際傳輸限制令風險。
  • 新加坡:PDPA 下資料中介(data intermediary)的保護與保留義務,以及 2021 年起生效的強制資料外洩通報門檻(依新加坡 PDPC 公布之規定)。
  • 歐盟:GDPR 第 28(3) 條的八項強制內容,以及因台灣未獲適足性認定而需搭配的 SCCs。

實務建議是維護一份「主條款 + 法域增補(jurisdictional addendum)」的模組化範本庫,用 Markdown 管理、用 Pandoc 產出 docx 給法務審閱:

1pandoc templates/dpa-core.md templates/addendum-tw.md \
2 --reference-doc=templates/legal-style.docx \
3 -o build/DPA-TW-vendorA.docx

Branch8 曾為一家在台灣與東南亞多市場營運的零售集團重建其供應商資料治理流程:把分散在各國子公司的廠商合約盤成單一 YAML registry,以 Git 管理版本、以 GitHub Actions 排程檢核,並將 DPA 範本拆為共通層與法域增補層。這個做法最大的改變不是文件變漂亮,而是「哪家廠商的個資條款過期了」從一個要發信問人的問題,變成一個查詢即得的答案。

常見實作障礙與排解方式

供應商拒絕接受無限責任

多數國際 SaaS 的標準條款會把個資責任納入總體責任上限。折衷做法:爭取個資專屬的較高上限(主約上限的 2–3 倍),並把主管機關罰鍰與當事人賠償明確列為可求償項目,而非歸類為「間接損害」而被排除。

供應商只提供英文版 DPA

可接受英文主文,但建議加簽一份中文的「台灣增補條款」,明確援引個資法條號與施行細則第 8 條各款。若發生爭議,台灣法院與主管機關看的是中文法律要件是否被涵蓋。

複委託清單永遠跟不上實際

不要在合約正文列舉複委託對象,改為援引供應商公開維護的 sub-processor 頁面,並約定訂閱變更通知。條文寫法:「附表二所列複委託對象,以受託者於〔URL〕公布且經甲方訂閱變更通知之清單為準。」

舊合約要不要全部重簽?

依風險排序,不要一次全翻。先處理:資料量大的、含特種個資的(病歷、健康檢查、犯罪前科等個資法第 6 條類別)、境外儲存的、以及會接觸原始個資而非彙總資料的廠商。其餘可在合約續約時一併更新。

事故通報窗口形同虛設

合約寫了 24 小時通報,但指定窗口是三年前離職員工的信箱。解法是在 registry 中加入 incident_contact 欄位並納入上述檢核腳本,每季發一封測試信確認可達。

Ready to Transform Your Ecommerce Operations?

Branch8 specializes in ecommerce platform implementation and AI-powered automation solutions. Contact us today to discuss your ecommerce automation strategy.

上線前的最後檢核清單

  1. 每家接觸個資的廠商都有簽署的 DPA,且 contract_ref 可追溯到實體文件。
  2. 附件二的技術措施與廠商實際交付的控制一致(別把 ISO 27001 證書當成技術措施清單)。
  3. 複委託清單已核准,且有變更通知機制。
  4. 境外儲存的廠商已完成國際傳輸評估並留存書面紀錄。
  5. 事故通報窗口(雙方)皆為現職人員,並已測試。
  6. 稽核排程已進入行事曆,而非「有空再說」。
  7. 若涉及 LLM 或 AI 服務,訓練資料使用禁止條款與資料留存設定已確認。
  8. 終止後資料銷毀證明的格式已事先約定,而非等到終止當天才開始協商。

委外個資合約的價值不在於訴訟時拿出來用,而在於它迫使你把資料流攤開來看。多數團隊在做完第一次 vendor registry 盤點後,第一個反應都是「原來我們的個資流到這麼多地方」。

如果你的團隊正在整頓跨市場的資料治理流程——無論是台灣的個資法、新加坡 PDPA,還是歐盟 GDPR 的疊加需求——Branch8 在香港、台灣、新加坡與東南亞的團隊協助企業把合規文件、供應商清單與技術控制接成同一套可自動檢核的流程。歡迎與我們聯繫討論你目前的資料流架構。

Sources

FAQ

個資法施行細則第 8 條規定委託機關應對受託者為適當監督,並明定監督事項,實務上主管機關與法院均以書面契約作為是否盡監督義務的核心證據。電子郵件與工單紀錄可作為日常指示的書面形式,但基礎監督事項仍應以正式契約或附件載明。

About the Author

Matt Li

Co-Founder & CEO, Branch8 & Second Talent

Matt Li is Co-Founder and CEO of Branch8, a Y Combinator-backed (S15) Adobe Solution Partner and e-commerce consultancy headquartered in Hong Kong, and Co-Founder of Second Talent, a global tech hiring platform ranked #1 in Global Hiring on G2. With 12 years of experience in e-commerce strategy, platform implementation, and digital operations, he has led delivery of Adobe Commerce Cloud projects for enterprise clients including Chow Sang Sang, HomePlus (HKBN), Maxim's, Hong Kong International Airport, Hotai/Toyota, and Evisu. Prior to founding Branch8, Matt served as Vice President of Mid-Market Enterprises at HSBC. He serves as Vice Chairman of the Hong Kong E-Commerce Business Association (HKEBA). A self-taught software engineer, Matt graduated from the University of Toronto with a Bachelor of Commerce in Finance and Economics.