隱私設計
隱私設計（privacy by design）是指：把個人資料的保護放進系統的設計與預設值裡，而不是在功能做完、產品上線之後再補上一份政策、一個同意視窗與一組權限設定。
這句定義的重量落在「設計與預設值」上。它主張的不是「要重視隱私」這種態度，而是一連串在寫程式之前就必須回答的具體設計問題：這個欄位為什麼要收？收了之後放多久？誰可以看到？使用者什麼都不做的時候，系統的行為是什麼？這些問題的答案會直接變成資料表結構、權限模型與預設選項，一旦寫下去就很難改——這正是它必須在前面做、而不是後面補的原因。
隱私設計與 風險登錄 的關係比直覺上更緊密：它不只是「降低外洩的可能性」，更常是直接縮小外洩的影響金額。這一點會在例子裡用算術說明。
隱私不等於資安
Section titled “隱私不等於資安”這是本文最重要的一條界線，混淆它會導致公司做了很多正確的事、卻沒有解決真正的問題。
- 隱私（privacy） 問的是：我們該不該持有這筆資料？基於什麼理由？可以用來做什麼？要留多久？
- 資安（security） 問的是：我們持有的東西，守不守得住？
兩者的關係是必要而不充分：沒有資安，隱私承諾一定跳票；但資安做到滿分，也不會讓一筆本來就不該收集的資料變得正當。一家公司可以擁有加密、存取控制與稽核紀錄一應俱全的系統，同時仍然在做一件有問題的事——收集與服務無關的個人資料、或把資料用在使用者從未預期的用途上。反過來，一家只收必要欄位的公司，即使技術能力普通，可能造成的傷害本來就小得多。
這條界線在工具層面也看得出來：NIST 對隱私與資安分別發布了不同的框架，隱私框架的定位是協助組織辨識與管理隱私風險，資安框架的定位則是協助組織管理資安風險。兩者是相關但各自獨立的管理對象，本身也都是自願性工具，不是法律義務。
反覆出現的原則是設計問題，具體義務不是通用的
Section titled “反覆出現的原則是設計問題，具體義務不是通用的”跨過不同的隱私法制，會反覆看到同一組原則：目的限定（先確定目的，再決定要收什麼）、資料最小化（只收達成目的所必需的）、保存期限限制（不再需要就刪除或去識別化）、透明（讓當事人知道你在做什麼）、當責（有一位具名的人對這件事負責）。
必須把這句話的兩半分開讀。原則層面的重複出現，讓它們可以當成設計時的檢查問題——這一半是穩定的、可以先做的。但掛在這些原則之下的具體法律義務並不統一：什麼樣的處理需要什麼法律依據、同意要用什麼形式取得、當事人有哪些請求權、跨境傳輸要滿足什麼條件、發生外洩時要在多久之內通知誰、以及未遵守的後果是什麼——這些因司法管轄區而異，而且時常修訂，不是全球通用。
因此本文刻意不寫任何期限、門檻或罰則的數字。可以先做的是設計；必須逐地確認的是義務。制度性差異見 隱私與數位服務的地區差異，實際案件請尋求當地合格的法律或隱私專業協助。
預設值比政策更能決定實際結果
Section titled “預設值比政策更能決定實際結果”第三條界線是關於行為，不是關於法律：**絕大多數使用者不會更改預設值。**這是產品設計裡最穩定的觀察之一，它的推論很直接——系統的預設狀態，就是幾乎所有使用者的實際狀態。
於是「我們提供了關閉選項」與「我們預設是關閉的」在文件上只差幾個字，在結果上是兩個世界。同理，一份寫得很完整的隱私政策，如果對應的預設是全部開啟、保存期限是永久、內部所有人都能查詢，那麼這份政策描述的只是可能性，不是現況。判斷一家公司的隱私實作，看預設值與資料表比看政策文件可靠得多。
這條界線也是隱私與 智慧財產 常被混淆的地方：公司可能對某個資料集擁有權利，卻仍不得為特定目的使用其中的個人資料。「我們有權利用這份資料」與「我們可以這樣用這份資料」是兩個獨立的問題。
Fact-backed example（教學數字，本系列共用的虛構公司「宏茂科技」，一家做消費者 App 的小型軟體公司，單位：元）：
公司的風險登錄上有一列是「客戶資料外洩」，可能性 5%、影響金額 20,000,000 元，期望損失 0.05 × 20,000,000 = 1,000,000 元／年。多數團隊看到這一列的直覺反應是降低可能性：加強存取控制、導入多因子驗證、做滲透測試。這些都對，但它們全部只作用在算式的左邊那一項。
隱私設計提供的是另一條路徑：減少持有的資料，直接縮小右邊那一項。
假設盤點後發現，App 註冊時收集的出生日期從未被任何功能使用——它當初被加進表單，只是因為「以後可能會做生日行銷」。停止收集並刪除既有欄位之後，這個欄位就再也不可能出現在任何外洩事件裡。沒有持有的資料不會外洩，這是一個不需要任何技術控制就成立的結論，也是資料最小化最直接的價值。
把它放進算式看。假設外洩影響金額由三部分構成：技術與調查處理 5,000,000、通知與客戶補償 9,000,000、業務損失與信任修復 6,000,000，合計 5,000,000 + 9,000,000 + 6,000,000 = 20,000,000 元，與登錄上的數字對得起來。再假設把非必要的身分識別欄位移除後，外洩事件的敏感度下降，使通知與補償一項降為 3,000,000、業務損失一項降為 4,000,000，其餘不變：新的影響金額 = 5,000,000 + 3,000,000 + 4,000,000 = 12,000,000 元。在可能性維持 5% 不變的情況下，期望損失 = 0.05 × 12,000,000 = 600,000 元／年，比原本的 1,000,000 元下降 400,000 元／年。
交叉檢查與限制要一起說。第一，影響金額下降 20,000,000 − 12,000,000 = 8,000,000，乘上 5% 得 400,000 元，與上面的差額一致，單位都是元／年。第二，這裡的組成、下降幅度與可能性全部是為了讓推導可驗算而設定的假設值，不是任何真實外洩事件的統計；讀者必須換成自己的估計。第三，也是真正要記住的一點：降低可能性的控制措施會失效，減少持有的資料不會——前者依賴人與系統持續正確運作，後者是一次性的、結構性的改變。第四，最小化有其上限：真正被功能需要的資料不能刪，硬刪會讓產品壞掉，所以這個動作的前提永遠是先做一次誠實的盤點，區分「用得到」與「當初順手收的」。
Failed alternative： 另一種做法是從另一家公司的網站複製一份隱私政策，改掉公司名稱後上線，並在對外問卷裡引用它。
它當時看起來相當合理：那家公司規模更大、法務資源更多，政策的內容看起來比自己寫得出來的完整；上線之後也確實沒有任何客訴，因為幾乎沒有人會逐字閱讀隱私政策；而且從結果看，公司比完全沒有政策的同業「更合規」。任何一次表面檢查都會給它通過。
它失效的假設是「政策文件描述的是義務，所以照抄不會有問題」。實際上隱私政策描述的是這家公司的實際作業——它保存多久、與誰共享、如何回應當事人請求、內部誰能存取。照抄的結果，是公司對外書面聲明了一套自己並沒有在執行的作業，而且是自己主動寫下來的。這比沒有政策更糟：它把一個原本模糊的落差，變成一份有日期、有簽章、可被逐條對照的證據。預警訊號很好認：政策裡提到公司根本沒有的部門或流程；提到的保存期限沒有任何系統在執行；提到的當事人請求管道沒有人負責收信；以及最典型的——沒有任何工程師參與過那份政策的撰寫或審閱。這條路徑的完整發展與代價，見 抄襲合規範本案例。
正確做法的順序是相反的：**先盤點實際在收什麼、放在哪裡、留多久、誰看得到，把不必要的部分砍掉，再把剩下的事實寫成政策。**政策是實作的描述，不是實作的替代品。
讀者會在四種決策裡再次用到隱私設計。做產品設計時，它是新功能規格裡應該與資料表一起被審的一段：這個欄位的目的是什麼、保存多久、誰能看到、預設值是什麼；隱私與資安課 會把這組問題與具體控制措施對應起來。做風險管理時，它提供了一條與技術控制不同的路徑——縮小影響而不是只壓低可能性——而每一次最小化的成果都應該回頭更新 風險登錄 上那一列的影響金額，否則登錄會持續高估。談廠商與合約時，公司交給第三方處理的個人資料通常仍由公司對外負責，因此存取範圍、保存期限與再委託的限制都必須寫進合約，見 合約與內部控制課。做盤點時，可以用 風險與智慧財產稽核練習 把資料清單與風險登錄一起做出來。
實務上的維護規則只有三條：每一個新增的個人資料欄位，都要在上線前寫下它的目的與保存期限，寫不出來就不要收；每一項預設值都要能說明為什麼是這個方向，因為它就是絕大多數使用者的實際狀態；每一份對外的隱私說明，都必須由實際知道系統怎麼運作的人審過一次，確認它描述的是現況而不是願望。
NIST Privacy Framework 官方頁 支持本文的一項定位主張：隱私風險是一個可以被獨立辨識與管理的對象，並且存在專門為此設計的工具。該頁說明此框架是「a voluntary tool developed in collaboration with stakeholders intended to help organizations identify and manage privacy risk to build innovative products and services while protecting individuals’ privacy」。兩項限制必須一併說明：它明示為 voluntary（自願性），不是法律義務；而且它是美國國家標準與技術研究院發布的工具，不是任何司法管轄區的法律要求。本文引用它，是為了支持「隱私應被當成一種風險來管理」，而不是主張任何公司必須採用它。
NIST Cybersecurity Framework (CSF) 2.0（CSWP 29） 支持另一半：資安是與隱私並列、但問題不同的管理對象，其框架的目的是協助各類組織管理資安風險。該文件同樣是自願性的，並且不規定結果要如何達成——如其說明所述，它「does not prescribe how outcomes should be achieved」，而是連結到其他實作指引。本文據此主張「資安是隱私的必要條件而非充分條件」，這一步是作者的 inference，兩份框架本身並未以這個句型陳述彼此的關係。該文件版本為 2.0，發布日期 2024-02-26。
OECD 公司治理原則中關於董事會職責的章節 支持「當責」這一項原則的治理基礎：重要事項必須有明確的最終答覆對象，而不是分散在所有人身上。本文把這個治理層的期待，向下轉譯為「每一類個人資料要有一位具名負責人」，這一步轉譯是作者的 inference。範圍限制：該原則為 non-binding（不具法律拘束力），且主要以公開發行公司為對象。
必須誠實標示的一點是：本文所列的目的限定、資料最小化、保存期限限制、透明、當責這一組原則，是作者從多套隱私法制與框架中觀察到的重複出現的設計問題（inference），本文並未引用單一法規或單一國際文件作為其權威定義，讀者也不應把它當成任何法律的條文清單。文中「宏茂科技」的外洩影響金額組成、下降幅度與 5% 可能性全部是教學 example，不是任何真實事件的統計；可能性 × 影響金額 的算術在給定假設下是確定性的，但假設本身是估計。凡涉及法律依據、同意形式、當事人權利、跨境傳輸條件、外洩通知對象與期限，或未遵守的後果，皆因地區而異且時常修訂，不是全球通用；請見 隱私與數位服務的地區差異，並就個案尋求當地合格的法律專業協助。三筆來源 accessed 2026-07-31。