ICO對英國組織的執法行動在2024年和2025年急劇增加，兩年間因技術安全措施不足而徵收的罰款總額超過1,200萬英鎊。ICO執法通知中呈現出一貫的規律：遭受資料洩露且無法證明已實施適當技術控制措施的組織面臨最嚴厲的處理結果。對開發者而言，這是一個直接的職業關切。您在加密、日誌記錄、存取控制和資料留存方面做出的決策，就是決定一個組織能否在ICO面前為自己辯護的技術控制措施。

本指南專為開發者和工程團隊編寫，而非法律或合規部門。它將UK GDPR的要求轉化為具體的技術決策：實施什麼、如何實施，以及每項措施存在的原因。

摘要

  • UK GDPR第32條要求與風險相稱的「適當技術措施」。對於大多數處理個人資料的應用程式，這意味著靜態和傳輸中的加密、可行時的假名化、存取控制以及有據可查的違規偵測能力。
  • 導致GDPR風險敞口的最常見開發者錯誤：在除錯輸出中記錄PII、軟刪除本應為滿足刪除權而硬刪除的記錄，以及未能與每個接觸個人資料的第三方服務簽訂DPA。
  • 資料最小化是在欄位層級做出的設計決策。如果您沒有收集和儲存某個欄位的書面理由，請勿收集。
  • 刪除權要求真正刪除，並透過所有系統（包括備份和第三方處理者）進行串聯。軟刪除無法滿足該義務。

UK GDPR與EU GDPR：對開發者意味著什麼變化

脫歐後，英國透過《2018年歐盟（退出）法》將EU GDPR框架保留為「UK GDPR」。對開發者而言，技術要求完全相同。差異在於行政層面：英國的監管機構是資訊專員辦公室（ICO），而非歐盟國家資料保護機構；英國與歐盟之間的跨境資料傳輸受英國充分性決定的約束（目前由歐盟維持，但會定期審查）。

實際含義是：如果您構建的軟體符合EU GDPR的技術要求，它同樣滿足UK GDPR的技術要求，反之亦然。差異將出現在通知程序、傳輸機制以及ICO具體執法指導方面，後者在側重點上有時與歐洲資料保護委員會（EDPB）的指導不同。

第32條：實際要求什麼

UK GDPR第32條要求資料控制者和處理者實施「適當的技術和組織措施」，以確保與風險相適應的安全等級，同時考慮技術現狀、實施成本以及處理的性質、範圍、背景和目的。

這一措辭有意保持彈性。在實踐中的含義取決於您的風險狀況，但第32條第1款給出了四個具體示例：

  1. 個人資料的假名化和加密
  2. 確保處理系統和服務持續保密性、完整性、可用性和韌性的能力
  3. 在發生物理或技術事故後及時恢復個人資料可用性和存取權限的能力
  4. 定期測試、評估和評價安全措施有效性的流程

「技術現狀」並不意味著您必須實施最昂貴或最前沿的解決方案。它意味著當明顯更優的方法（如Argon2）已經完善、廣泛可用且實施成本並無實質性提升時，您無法為使用弱方法（如MD5密碼雜湊）進行辯護。

靜態加密

密碼。 切勿以明文儲存密碼，切勿使用MD5或SHA-1進行密碼雜湊處理。兩者均完全不適用。請使用工作因子至少為12的bcrypt，或參數調整為在伺服器硬體上至少耗時100毫秒的Argon2id。Argon2id是OWASP的當前建議，新實施時應優先選用。

1# Argon2id with libsodium (Node.js example)
2const hash = await argon2.hash(password, {
3  type: argon2.argon2id,
4  memoryCost: 65536,   // 64 MB
5  timeCost: 3,
6  parallelism: 1
7});

資料庫加密。 在資料庫層級啟用靜態加密。所有主流資料庫和受管服務（PostgreSQL、MySQL、MongoDB Atlas、AWS RDS、Azure SQL）均支援此功能。透明資料加密（TDE）保護磁碟上的資料，但無法防範擁有查詢存取權限的已受損資料庫使用者。對於高度敏感的欄位（國家保險號、醫療記錄、金融帳號），請考慮使用金鑰管理服務（AWS KMS、Azure Key Vault、HashiCorp Vault）的AES-256-GCM進行應用程式層欄位加密。金鑰必須與其加密的資料分開儲存。

金鑰管理。 請勿在應用程式程式碼中硬式編碼加密金鑰，也不要將其與其保護的資料儲存在同一資料庫中。開發環境使用環境變數，生產環境使用受管金鑰管理服務。定期輪換金鑰，並確保您的應用程式能夠在不停機的情況下處理金鑰輪換。

避免的做法。 請勿在加密可能不適用的日誌檔案、暫存檔案或應用程式快取中儲存明文個人資料。檢查處理個人資料的每條程式碼路徑，確保不會無意中儲存未加密的副本。

傳輸中加密

TLS組態。 強制實施TLS 1.2為最低版本，在受支援的情況下將TLS 1.3設為預設值。完全停用SSLv3、TLS 1.0和TLS 1.1。在nginx上：

1ssl_protocols TLSv1.2 TLSv1.3;
2ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
3ssl_prefer_server_ciphers off;

HSTS。 設定帶有較長max-age值和includeSubDomains的Strict-Transport-Security標頭。至少31536000（一年）的max-age是標準做法。如果您的部署允許，請提交到HSTS預載清單。

1Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

混合內容。 從HTTPS頁面透過HTTP提供任何資源（圖像、指令碼、樣式表、API呼叫）會產生混合內容漏洞並削弱傳輸安全性。設定內容安全性原則以封鎖混合內容，並檢查您的頁面是否有任何非HTTPS資源載入。

內部服務。 傳輸中加密同樣適用於內部服務間通訊，而不僅限於面向使用者的流量。資料庫連線、訊息佇列連線和微服務呼叫都應使用TLS。許多開發者正確加密了面向使用者的層，卻忽視了內部網路。

程式碼中的資料最小化

資料最小化不是法律抽象概念。它是逐欄位做出的設計決策。在收集任何個人資料之前，請自問：應用程式是否真的需要這些資料才能運行？如果您無法用具體的使用場景回答這個問題，請勿收集。

在實踐中，這意味著：

  • 刪除選用且目的模糊的表單欄位（例如在無年齡驗證要求的電子報訂閱頁面上的「出生日期」欄位）
  • 定期審查資料庫綱要，刪除包含未被積極使用的個人資料的欄
  • 盡可能在綱要層面設定留存期，使用排程工作自動清除過期記錄
  • 避免收集高度敏感的個人資料（健康資訊、財務細節、政治觀點），除非您的應用程式確實需要，因為第32條風險評估隨處理資料的敏感性而提高

ICO的問責原則要求您能夠證明已考慮過資料最小化。架構設計或迭代筆記中的書面設計決策可滿足此要求，未書面記錄的決策則不能。

假名化

假名化將直接識別資訊替換為在沒有存取單獨儲存的金鑰或對應表的情況下無法識別個人的權杖或識別碼。第32條將其明確列為建議的技術措施，第89條為將假名化資料用於研究目的的處理規定了減少的義務。

對於分析和行為追蹤，常見模式是在將使用者識別碼傳遞給分析系統之前，使用網站特定的鹽透過SHA-256對其進行雜湊處理：

1import hmac, hashlib
2
3def pseudonymise(user_id: str, site_secret: str) -> str:
4    return hmac.new(
5        site_secret.encode(),
6        user_id.encode(),
7        hashlib.sha256
8    ).hexdigest()

鹽必須與分析資料分開儲存。沒有鹽，雜湊值就無法逆推以識別個人。這意味著您的分析系統只持有假名化識別碼，從而降低了該系統遭受資料洩露的風險狀況。

假名化不是匿名化。如果您持有對應金鑰，ICO會將假名化資料視為個人資料。完全匿名化是指即使使用合理可能獲得的附加資訊也無法進行重新識別，這將使資料完全脫離GDPR的適用範圍。在實踐中實現真正的匿名化很困難；大多數實施產生的是假名化資料，仍受GDPR約束，但風險已降低。

刪除權：正確實施

刪除權（第17條）是GDPR中技術實施難度最高的義務之一。要求具體如下：

硬刪除，而非軟刪除。 設定is_deleted旗標並將其從查詢中篩選掉並不滿足刪除權。資料必須從資料庫中實際刪除。為每個持有個人資料的實體構建硬刪除功能。

串聯刪除。 如果個人資料還儲存在關聯資料表中（訂單、地址、活動日誌、偏好設定、上傳檔案），僅刪除使用者記錄是不夠的。對應每個包含與使用者識別碼關聯的個人資料的資料表，確保刪除操作正確串聯，或實施顯式刪除工作以原子方式刪除所有關聯資料。

第三方處理者。 如果您已將個人資料傳送給第三方服務（電子郵件行銷平台、CRM、分析工具、付款處理商），您的刪除義務延伸至指示該處理者刪除資料。這需要：

  • 記錄接收個人資料的每個第三方服務的清單
  • 為每個服務確認刪除機制（API呼叫、支援工單、自動化資料主體請求處理）
  • 證明刪除已完成的證據

備份。 備份是最常被忽視的刪除問題。如果您的資料庫每日備份保留期為90天，則在即時資料庫中滿足的刪除請求在備份到期之前不會在備份中得到滿足。ICO的立場是，在刪除後還原的備份不得重新引入已刪除的個人資料。實際方法包括：在可行時從備份匯出中排除已刪除的記錄、實施備份專用清除流程，或使用欄位層級加密並刪除金鑰（使資料無法讀取，這接近刪除標準）。

例外情況。 刪除權並非絕對。您可以保留法律主張、法定合規（例如《公司法》規定的財務記錄）或公共利益目的所必需的資料。記錄例外情況，並在拒絕或部分履行刪除請求時告知資料主體。

違規偵測與72小時通知要求

UK GDPR第33條要求您在得知可能給個人帶來風險的個人資料洩露後72小時內通知ICO。這不是從違規發生起計算的72小時，而是從您得知違規起計算的72小時。這一區別為建立違規偵測能力提供了直接激勵，因為時鐘從您發現違規時開始計時。

違規偵測需要記錄的內容。 您的日誌架構應捕獲：

  • 身份驗證事件：成功和失敗的登入、MFA挑戰、密碼重設
  • 授權失敗：因權限檢查被拒絕的請求
  • 資料存取：誰在何時存取了哪些個人資料，尤其是大量匯出或異常的查詢量
  • 組態變更：使用者權限、加密金鑰或資料留存設定的變更
  • 異常模式：來自異常IP位址或在異常時間的存取，對個人資料表的大量讀取

不應記錄的內容。 請勿在應用程式日誌中記錄個人資料值。記錄完整請求正文、帶有參數值替換的資料庫查詢或使用者輸入表單資料的除錯日誌會建立難以管理且本身在GDPR範圍內的次級個人資料儲存。記錄識別碼（使用者ID、工作階段ID、請求ID）而非值。

1# 錯誤：記錄實際電子郵件地址
2logger.debug(f"Login attempt for user {request.form['email']}")
3
4# 正確：僅記錄識別碼
5logger.debug(f"Login attempt, user_id={user.id}, request_id={request_id}")

違規回應規劃。 日誌記錄使偵測成為可能，但您需要一個書面流程，明確在偵測到違規時該做什麼。誰在內部收到通知？誰做出ICO通知決定？ICO通知需要包含哪些資訊？在需要之前就建立好這個流程。

第三方API合規

控制者與處理者。 如果您使用第三方服務代表您處理個人資料（交易電子郵件提供商、雲端基礎設施提供商、付款處理商），他們是資料處理者，您是資料控制者。在該背景下，您對他們遵守UK GDPR負責。

資料處理協議。 您必須與每個代表您處理個人資料的第三方服務簽訂書面資料處理協議（DPA）。大多數主流SaaS提供商（AWS、Mailchimp、Stripe、Twilio、SendGrid）提供標準DPA。簽署並儲存這些協議。如果提供商無法提供DPA，您在UK GDPR下不能合法使用他們處理個人資料。

次級處理者。 您與處理者的DPA應列出其次級處理者（他們依次用於處理您資料的服務）。例如，您的交易電子郵件提供商可能使用AWS基礎設施。您不需要與次級處理者直接簽訂DPA，但為了傳輸合規目的，您需要了解他們是誰以及資料在地理上在哪裡被處理。

傳輸機制。 如果第三方服務在英國或歐盟以外處理資料，您需要建立合法的傳輸機制。對於從英國進行的傳輸，目前是英國特定機制（英國國際資料傳輸協議，或在可用時依賴英國充分性決定）。檢查每個服務的資料駐留選項和傳輸文件。

存取控制

最小權限原則。 您的應用程式使用的資料庫使用者應擁有所需的最小權限：對特定資料表的讀寫存取，無管理員存取權限。為讀取密集型服務（報告、分析）和寫入密集型服務（面向使用者的應用程式）建立單獨的資料庫憑據。這限制了憑據被攻破的爆炸半徑。

基於角色的存取控制。 在您的應用程式中實施RBAC，定期審查角色指派。角色隨時間會累積權限；定期對照每個角色實際需要的內容進行稽核可以發現權限蔓延。

資料存取稽核日誌。 對於敏感資料，在應用程式層實施稽核日誌，記錄哪個經過身份驗證的使用者在何時存取了哪條個人資料記錄。這與應用程式錯誤日誌是分開的，並且應該是防竄改的（一次寫入或僅附加，應用程式程式碼的存取受限）。

開發者檢查清單：需要實施的10項技術控制

  1. 密碼雜湊。 使用bcrypt（成本因子12+）或Argon2id。立即刪除任何MD5或SHA-1密碼雜湊。
  2. 靜態加密。 啟用資料庫層級的TDE，並對金鑰儲存在受管KMS中的高度敏感個人資料實施欄位層級AES-256-GCM加密。
  3. TLS組態。 強制實施TLS 1.2最低版本、TLS 1.3預設、一年max-age的HSTS，無混合內容。
  4. 資料最小化稽核。 審查資料庫綱要中所有包含個人資料的欄位。刪除或停止收集任何沒有書面活躍使用場景的欄位。
  5. 硬刪除實施。 為與使用者關聯的所有個人資料構建經過驗證的串聯刪除。測試刪除操作確實刪除了記錄而非僅僅標記它們。
  6. 第三方DPA清單。 列出每個接收個人資料的SaaS或雲端服務。確認每個服務均有簽署的DPA。刪除無法提供DPA的任何服務。
  7. 日誌衛生。 稽核您的應用程式日誌中是否存在PII。在每個日誌層級的日誌輸出中刪除個人資料值。僅記錄識別碼。
  8. 違規偵測日誌。 為身份驗證事件、授權失敗和大量資料存取實施結構化日誌記錄。為異常模式設定警示。
  9. 存取控制審查。 根據最小權限原則稽核資料庫憑據和應用程式角色。從應用程式資料庫使用者中刪除管理員存取權限。
  10. 分析假名化。 在分析和第三方追蹤呼叫中，用使用網站特定金鑰的HMAC雜湊值替換直接使用者識別碼。

關鍵要點

  • UK GDPR的技術要求與EU GDPR完全相同。脫歐後由ICO負責執法，您需要遵循ICO關於通知和傳輸的具體指導。
  • 第32條要求與您的風險相稱的適當技術措施。對於大多數應用程式，這意味著強加密、存取控制、假名化和有據可查的違規偵測。
  • 資料最小化是開發者在欄位層級做出的決策，不是法律抽象概念。如果您無法證明收集某個欄位的必要性，請勿收集。
  • 刪除權要求透過所有系統（包括備份和第三方處理者）進行真正的串聯刪除。軟刪除旗標無法滿足該義務。
  • 請勿記錄個人資料值。記錄識別碼。您的日誌檔案本身就是個人資料儲存，也是最常被忽視的違規攻擊向量之一。
  • 與每個接觸個人資料的第三方服務簽訂已簽署的DPA。如果提供商無法提供DPA，您就無法合法地將其用於該目的。

常見問題解答（FAQ）

如果我的所有使用者都在英國以外，UK GDPR是否適用？ UK GDPR適用於在英國設立的組織，無論使用者在哪裡。它也適用於在英國境外向英國境內人士提供商品或服務、或監控英國境內人士行為的組織。如果您是總部位於英國的開發者，為非英國受眾構建應用程式，UK GDPR同樣適用於您的處理活動。

UK GDPR下加密是強制性的嗎？ 加密在第32條第1款(a)項中被明確列為建議措施。由於法規要求「與風險相稱」的措施，加密並非絕對強制要求。但實際上，對於任何在網際網路上處理個人資料的應用程式，若不對傳輸中和靜態資料進行加密，將很難向ICO提出合理解釋。請將其視為必須實施的措施。

什麼情況構成需要ICO通知的個人資料洩露？ 個人資料洩露是指對個人資料的任何意外或非法銷毀、遺失、更改、未經授權披露或存取。這包括組態錯誤導致記錄公開的S3儲存貯體、網路釣魚攻擊使攻擊者存取了包含客戶資料的電子郵件帳戶，以及意外刪除無備份的記錄。並非所有洩露都需要ICO通知，只有可能給個人帶來風險的才需要。高風險洩露還需要直接通知受影響的個人。

我們需要保留個人資料多長時間？ UK GDPR不規定具體的留存期。您只能在收集個人資料的目的所必需的時間內保留資料。為您持有的每類資料定義留存期，在隱私聲明中記錄，並實施自動清除。根據《公司法》，財務記錄通常保留六年。行銷同意記錄應保留至同意被撤回或到期為止。

我們需要資料保護長嗎？ DPO對公共機構、大規模處理敏感個人資料的組織以及開展大規模系統性監控的組織是強制性要求。對於大多數英國軟體公司而言，DPO並非強制性要求，但如果您處理大量個人資料，則建議配置。ICO在其網站上就這一門檻提供了具體指導。

UK GDPR不合規的最高罰款是多少？ ICO可對最嚴重的違規行為處以最高1,750萬英鎊或全球年營業額4%（以較高者為準）的罰款。對較輕微違規行為，適用最高870萬英鎊或全球營業額2%的較低檔罰款。實際上，大多數ICO罰款遠低於上限，並根據違規的嚴重程度、組織的配合程度以及為補救問題所採取的措施進行調整。