Privacy by Design 隱私設計原則：產品開發怎麼落實？
Privacy by Design（隱私設計）是在產品與系統設計之初，就把個資保護做進需求、架構與預設設定，而不是上線後才補救的方法。這個概念由加拿大安大略省前資訊與隱私專員 Ann Cavoukian 提出，2010 年獲國際資料保護與隱私專員大會決議採納，歐盟 GDPR 第 25 條再把它寫成控制者的法定義務。
對軟體公司與 SaaS 業者來說，隱私設計早已不只是理念。海外客戶的資安問卷會問「新功能如何落實 data protection by design」，導入 ISO 27701 時也有對應的控制措施。以下把七大原則轉成開發流程中的檢查點，並附一份 PM 與工程師可直接使用的清單；若想把這套做法納入管理制度，可參考ISO 27701 驗證輔導。
Privacy by Design 是什麼？和資安有什麼不同
Privacy by Design 是一套設計方法，要求在決定「蒐集什麼、怎麼處理、保存多久、誰看得到」的當下就考慮隱私，讓保護措施成為系統的一部分。GDPR 第 25 條第 1 項的寫法是：控制者在決定處理方式時與實際處理時，都應採取適當的技術與組織措施，例如假名化，以有效落實資料最小化等原則。
它和資安的差別在提問的方向。資安問的是「資料要怎麼防止被偷」，隱私設計先問「這筆資料需不需要存在」。一個加密完善卻蒐集了身分證字號的會員系統，資安做得很好，隱私設計卻不及格。實務上，我們在審查 SaaS 產品時最常看到的問題，正是欄位比功能需要的多出一大截。
ISO/IEC 27701 對控制者訂有「隱私設計與預設隱私」控制群組（2019 年版為 A.7.4，2025 年版列於 A.1.4），涵蓋限制蒐集與處理、最小化目標、處理結束時去識別或刪除、暫存檔與保存期限等項目。ISO 27701 的完整架構可另行參考。
隱私設計七大原則：每一條對開發代表什麼
Cavoukian 的七大原則是性質描述，不是操作步驟。下表把每一條轉成產品團隊聽得懂的做法。
| 原則 | 原文 | 對產品開發的意思 |
|---|---|---|
| 1. 主動預防，而非事後補救 | Proactive not Reactive | 需求審查就問隱私問題，不等客訴或外洩 |
| 2. 預設即隱私 | Privacy as the Default Setting | 使用者什麼都不做，也只處理必要資料 |
| 3. 隱私嵌入設計 | Privacy Embedded into Design | 隱私是架構的一部分，不是外掛模組 |
| 4. 完整功能、正和而非零和 | Full Functionality | 不用「為了功能只好犧牲隱私」當藉口 |
| 5. 端到端安全 | End-to-End Security | 從蒐集到刪除的整個生命週期都有保護 |
| 6. 可見與透明 | Visibility and Transparency | 告知內容與實際處理一致，可被稽核 |
| 7. 尊重使用者隱私 | Respect for User Privacy | 設定好找、同意好撤回、介面不誘導 |
第 4 條最常被誤解。它不是要團隊放棄功能，而是要求找出兩者兼顧的設計，例如用統計資料取代個人明細，或改在使用者裝置端處理。
產品開發流程中的 6 個隱私檢查點
把隱私設計落到流程裡，最有效的方法是在既有的開發節點加上檢查點，而不是另開一套流程。下表以兩週一個衝刺的團隊為例（實務做法，可依團隊調整）。
| 階段 | 檢查點 | 負責人 | 產出 |
|---|---|---|---|
| 需求 | 每個個資欄位都對應到一個功能目的 | PM | 欄位與目的對照表 |
| 設計 | 判斷是否屬高風險處理，需要影響評估 | PM、法遵 | 風險初判紀錄 |
| 架構 | 決定加密、假名化、存取權限與保存期限 | 架構師 | 資料流程圖 |
| 開發 | 日誌與錯誤訊息不寫入明文個資 | 工程師 | 程式碼審查紀錄 |
| 測試 | 測試環境不使用正式個資 | QA | 去識別化測試資料 |
| 上線 | 預設值、告知文字、刪除功能都已就緒 | PM、法遵 | 上線檢查表 |
上線前，PM 與工程師可以用下面這份清單自我檢查：
- ☐ 每個欄位都說得出用途，拿掉會讓功能壞掉。
- ☐ 選填欄位預設不勾，行銷同意預設關閉。
- ☐ 個人頁面、分享連結預設不公開。
- ☐ 有設定保存期限，到期會自動刪除或去識別化。
- ☐ 後台權限依角色分開，查詢個資會留下紀錄。
- ☐ 使用者能自行下載、更正或刪除自己的資料。
- ☐ 第三方 SDK 與分析工具收集的內容已逐一確認。
- ☐ 隱私權政策已同步更新新功能的處理內容。
預設隱私（Privacy by Default）要做到哪裡？
預設隱私是指使用者不做任何操作時，系統只處理每個特定目的所必要的個資。GDPR 第 25 條第 2 項把範圍講得很具體：蒐集的數量、處理的程度、保存期間與可存取性四個面向都要符合，且預設不得讓個資在當事人未介入的情況下，被不特定多數人存取。
這條規定已有重罰案例。愛爾蘭資料保護委員會 2023 年 9 月對 TikTok 處以 3.45 億歐元罰款，理由之一是 13 至 17 歲使用者的帳號預設為公開，被認定違反第 25 條第 1、2 項。對 B2B SaaS 而言，類似的地雷通常不在帳號公開，而在後台：新進員工預設看得到全部客戶資料、匯出功能沒有權限控管、操作日誌永久保存。
範例：SaaS 新增「客戶生日提醒」功能
以一家做 CRM 的軟體公司為例，業務部希望新增「客戶生日自動寄祝賀信」。依前面的檢查點走一次，結果和直覺做法差很多。
需求階段，PM 發現只需要月日，不需要出生年份，欄位因此改為「生日月日」。設計階段確認這不屬高風險處理，但寄信屬行銷用途，必須另外取得同意，且預設關閉。架構階段決定生日欄位只有負責該客戶的業務看得到，匯出報表預設不含此欄。上線前，隱私權政策補上這項用途，並在客戶設定頁提供一鍵關閉。
整個調整多花了兩天討論，但上線後不必再回頭改資料庫結構。若功能涉及 AI 模型或自動化判斷，風險會高出許多，可先參考 AI 資安風險的整理。
各階段最常見的 4 個錯誤
第一，把隱私審查放在上線前一天，結果只能改告知文字，改不了設計。第二，測試環境直接複製正式資料庫，外洩風險反而比正式環境高。第三，第三方 SDK 預設收集裝置資訊與位置，開發團隊卻不知道。第四，保存期限寫在政策裡，系統卻沒有任何刪除機制。
這四項也是 ISO 27701 認證稽核時常被開出的缺失，越早修正，成本越低。
下一個功能開發前，先問哪三個問題？
下次開需求會議時，請 PM 先回答三個問題：這個功能少了哪個欄位就做不出來？資料要留多久、到期誰刪？使用者什麼都不設定時，誰看得到這些資料？三題答得出來，隱私設計就已經完成一半。
想把這套檢查點寫進公司的開發規範，並與 ISO 27701 的控制措施對齊，歡迎直接與顧問聊聊貴公司的狀況。
Privacy by Design 常見問題
法規有要求 Privacy by Design 嗎？
有。GDPR 第 25 條明定控制者須落實資料保護設計與預設，違反時依第 83 條第 4 項最高可處 1,000 萬歐元或全球年營業額 2%，取高者。台灣個資法沒有同名條文，但第 5 條要求蒐集、處理或利用不得逾越特定目的之必要範圍，實質上就是最小化要求。
Privacy by Design 和 DPIA 有什麼關係？
DPIA（資料保護影響評估）是針對可能造成高風險的處理所做的評估，GDPR 第 35 條要求在處理前完成；隱私設計則是貫穿整個開發流程的方法。實務上，DPIA 是隱私設計在「設計」檢查點會用到的工具：初判屬高風險時才啟動，評估結果再回頭影響架構決策。
隱私設計會增加開發成本嗎？
前期會多花一些討論時間，但通常比事後補救便宜。上線後才修改資料庫結構、補做刪除功能或回應主管機關調查，花費往往遠高於需求階段多開一次會。ISO 31700-1:2023 也從消費者保護角度提出隱私設計的高階要求，可作為產品規劃的參考。
參考資料
- GDPR 第 25 條 Data protection by design and by default – 資料保護設計與預設義務原文。歐盟 · 2016 年 4 月 27 日通過，2018 年 5 月 25 日適用
- Guidelines 4/2019 on Article 25 Data Protection by Design and by Default – 第 25 條解釋與實務範例。歐洲資料保護委員會 · 2020 年 10 月 20 日第 2.0 版
- Privacy by Design: The 7 Foundational Principles – Ann Cavoukian 七大原則原文（日本總務省收錄版）。安大略省資訊與隱私專員辦公室
- DPC announces €345 million fine of TikTok – 未成年帳號預設公開違反第 25 條。愛爾蘭資料保護委員會 · 2023 年 9 月 15 日
- ISO 31700-1:2023 Privacy by design for consumer goods and services – 消費性產品隱私設計高階要求。ISO · 2023 年 1 月
