
GDPR 安全要求:合規檢查清單與指南
GDPR 安全要求規定依據風險的技術控制措施,見於第 25 條與第 32 條。本指南涵蓋執法、罰則與合規檢查清單。

什麼是 GDPR 安全要求?
未履行資料外洩通報義務使 Meta 付出數百萬代價。違反第 25 條隱私設計原則則帶來更高額的罰款。這些並非假設情境。它們是愛爾蘭 DPC 2024 年度報告中記錄的執法行動,並顯示出為何 GDPR 安全要求在 2026 年仍是首要合規重點。
近期事件從帳本的另一端顯示出相同的模式:攻擊本身。根據 MGM 8-K,MGM Resorts 表示,2023 年 9 月的網路攻擊將對其 2023 年第三季業績造成約 1 億美元的負面影響。在美國,根據 FTC settlement,FTC 表示 Equifax 在其 2017 年資料外洩事件暴露消費者資料後,同意達成最高 5.75 億美元的和解。GDPR 安全要求的存在,是為了防止此類事件升級為持久性的財務與營運損害。
GDPR 安全要求是指 技術性與組織性措施,即《一般資料保護規則》第 25 條與第 32 條要求任何處理 EU/EEA 居民個人資料的組織必須採取的措施。GDPR 刻意保持技術中立,並未列出特定工具或規定特定解決方案。相反地,它要求您根據有文件記錄的 GDPR 風險評估 實施「適當的技術性與組織性措施」,並將現有技術水準、實施成本以及您的處理活動性質納入考量。
第 32 條明確列出四類措施:
- 假名化 與個人資料加密
- 確保持續維護處理系統之機密性、完整性、可用性與韌性的能力
- 在事件發生後及時恢復個人資料存取能力的能力
- 定期測試與評估您的安全控制措施有效性的流程
第 25 條再增加兩項義務:從一開始就將資料保護納入系統設計,以及預設僅處理必要的最低限度個人資料。
執法風險相當重大。監管機關持續針對安全措施不足開出高額罰款,如 Enforcement Tracker 所追蹤。要理解這些要求,首先必須了解它們如何與您現有的安全營運相連,以及其適用對象為何。
.jpg?width=2560&quality=90&format=auto)
GDPR 安全要求與資安的關聯
GDPR 安全要求與資安營運有直接重疊,但兩者並不相同。您的資安計畫保護系統、網路與資料免受攻擊。GDPR 安全要求則特別著重於保護您所處理之個人資料相關個體的權利與自由。
在實務上,您現有的安全控制措施構成 GDPR 合規的基礎。端點防護、存取管理、加密與事件回應皆有所貢獻。但 GDPR 增加了您的安全堆疊必須處理的特定義務:第 33 條規定的 72 小時資料外洩通報時限、用於評估外洩範圍與影響的鑑識能力、持續文件化以證明您的措施屬於適當,以及定期測試,且不僅止於滲透測試,而是評估您的整體安全計畫是否仍與風險相稱。若要了解 SOC 工作流程脈絡,請將此與 XDR fundamentals 對照。
這種關聯不僅止於共用工具。 EDPB Security digest 確認,監管機關評估的是您所實施的措施在當時情況下是否適當,而不是您是否防止了所有可能的外洩。這表示您的資安態勢就是您的合規態勢。薄弱的端點防護、緩慢的事件回應,以及跨環境可視性零散,都會直接轉化為監管風險。
GDPR 安全要求適用對象
GDPR 的適用範圍遠超 EU。根據 第 3 條,這些安全要求適用於任何處理位於 EU/EEA 之個人個人資料的組織,不論該組織本身位於何處。總部位於美國、儲存歐洲客戶紀錄的 SaaS 公司;擁有 EU 員工的亞洲製造商;以及向 EU 地址出貨的巴西電子商務網站,只要處理 EU 個人資料,皆屬適用範圍。
控制者(決定資料為何以及如何處理的組織)與處理者(代表控制者處理資料的第三方)皆依第 32 條負有直接安全義務。規模本身並不構成豁免。雖然 第 30 條 對員工少於 250 人的組織放寬部分紀錄保存義務,但當處理活動涉及資料主體風險、並非偶發性,或包含敏感資料類別時,仍然適用。若您的組織以任何常態方式接觸 EU 個人資料,GDPR 安全要求即適用於您。
在確立適用範圍與其和資安的關係後,下一步是詳細了解各項核心要求。
GDPR 核心安全要求
GDPR 安全義務涵蓋兩項主要條文,各自針對資料保護的不同階段。以下說明各條文對您的安全團隊有何要求。
- 加密與假名化(第 32(1)(a) 條): 第 32 條明確指出,加密與假名化屬於適當措施。 EDPB Guidelines 01/2025 on Pseudonymisation 將其定義為:以某種方式處理個人資料,使其在沒有另外保存的補充資訊時,無法歸屬於特定個人。您需要對靜態資料、傳輸中資料及備份進行加密,並依據 ICO guidance 採用集中式金鑰管理。關於實作基礎,請參閱加密基礎知識。
- 機密性、完整性、可用性與韌性(第 32(1)(b) 條): 此要求在傳統 CIA 三元組之外加入了韌性。 EDPB Security digest 將「具備個別驗證的適當存取控制機制」視為監管機關審查 合規性 時經常關注的重點。您需要角色型存取控制、對處理個人資料的系統採用多重要素驗證,以及依知悉必要性原則制定的存取政策。
- 及時復原(第 32(1)(c) 條):第 32(1)(c) 條要求在發生實體或技術事件後,具備及時恢復個人資料可用性與存取權限的能力,使備份、災難復原與回復能力成為明確的法規要求。
- 定期測試(第 32(1)(d) 條):安全測試是持續性的強制義務。ENISA 指引建議對高風險處理環境每季進行一次 滲透測試。
- 設計與預設隱私(第 25 條):第 25 條要求將資料保護納入設計與預設:您必須從設計階段就將隱私控制建置於架構中,而不是在部署後再附加上去,且預設僅處理必要的最少資料。
- 72 小時內通報資料外洩(第 33 條):當發生個人資料外洩時,您必須在知悉後 72 小時內通知您的監管機關。 EDPB Guidelines EDPB Guidelines 9/2022 允許分階段通報,但一旦您對個人資料已遭洩露達到合理程度的確信,時鐘就開始計時。您的流程也應對應現代 事件回應工作流程。
這些要求構成一個相互連結的系統。了解法規要求是一回事,理解這些要求在實務上如何共同運作則是另一回事。
GDPR 安全要求如何運作
GDPR 安全要求是透過 GDPR 風險評估框架運作,而非靜態的檢查清單。 EDPB Guidelines EDPB Guidelines 4/2019 指出,在選擇安全措施時,您必須評估四項強制因素:
- 最新技術水準: 您必須實施反映當前技術能力的措施。2018 年被視為「適當」的措施,到 2026 年可能已不足夠。
- 實施成本:措施必須符合比例原則,但 EDPB 警告,控制者不應將成本作為「避免實施資料保護」的藉口。
- 處理的性質、範圍、背景與目的: 您處理哪些資料、數量多少、在哪裡、為何處理,以及處理多久,都會影響所需的安全態勢。
- 風險發生的可能性與嚴重性:包括對個人權利與自由造成影響的機率與潛在衝擊。
如果您無法說明控制措施如何反映這四項因素,在資料外洩調查期間,您將難以為其「適當性」進行辯護。
從評估到實作的循環
您的 GDPR 安全流程會以持續循環的方式運作。首先盤點所有處理活動,接著進行風險評估,包括依據第 35 條針對高風險處理進行正式的資料保護影響評估(DPIA)。接著,選擇並實施技術與組織措施,並為第 5(2) 條的問責要求記錄所有內容。最後,隨著處理活動、技術與威脅的演變,定期測試並更新控制措施。
實務中的資料外洩回應
當事件發生時,您的回應會遵循特定順序:
- 判定個人資料是否已遭洩露
- 評估受影響個人的風險
- 若存在風險,請在 72 小時內通知您的監管機關
- 若風險很高,請直接通知受影響個人
第 33(5) 條要求您記錄每一次資料外洩,無論是否需要通報,內容包括發生了什麼事、造成的影響,以及已採取的補救措施。
處理者義務
如果您使用第三方處理者,第 28 條要求您僅委任能提供充分安全保證的處理者。依據第 33(2) 條,處理者必須在「無不當延遲」的情況下通知您資料外洩事件,而您需要具約束力的資料處理協議,涵蓋安全措施、次處理者管理及稽核權。
這個相互連結的框架為企業安全團隊帶來特定挑戰,而未達要求所造成的財務後果也相當具體。
GDPR 安全要求 | 罰則與執法
GDPR 罰款遵循 第 83 條。違反第 25 條與第 32 條這些核心安全要求,屬於較低級距:最高可處以 1,000 萬歐元罰款,或全球年度營業額的 2%,以較高者為準。違反基本處理原則、資料主體權利或國際傳輸規則,則屬於較高級距:最高可處以 2,000 萬歐元罰款,或全球年度營業額的 4%。
在實務上,監管機關在設定罰款金額時會衡量多項因素:違規的性質與嚴重程度、您是故意還是過失行事、您採取了哪些步驟來減輕損害,以及您的合規歷史。在調查期間與監管機關合作可減輕處罰,而不合作則可能加重處罰。
財務風險不僅限於監管罰款。 第 82 條 賦予個人就因違反 GDPR 所造成的物質或非物質損害尋求賠償的權利。歐盟各司法管轄區針對資料外洩的集體訴訟型態請求正在增加,這意味著單一安全失誤可能同時引發監管罰款與民事訴訟。對安全團隊而言,這使得控制薄弱的成本可以用直接財務數字衡量,而不只是營運風險。
這些風險使後續的營運挑戰更具急迫性。
實施 GDPR 安全要求的挑戰
即使有明確的監管框架與可量化的財務風險,將 GDPR 安全要求落實到實務中仍會產生營運摩擦,而這點往往被大多數合規指南低估。以下是企業安全團隊最常遇到的挑戰。
- 72 小時計時問題: 資料外洩通報時限是 GDPR 所帶來最困難的營運問題之一。當您的 SOC 團隊管理來自數十種彼此分離的安全工具警示時,要跨端點、雲端環境與身分系統關聯資料,以判定個人資料是否遭到入侵,所需時間往往超出您所能負擔。能夠整合端點、雲端與身分遙測的平台,有助於縮短這段關聯分析時間。
- 影子資料與資料盤點落差: IAPP's 影子資料分析 強調,個人資料會累積在備份、封存與舊版系統中,而組織往往無法完整追蹤或刪除這些資料。您無法保護自己不知道存在的個人資料。
- 「現有技術水準」的不斷變動目標: 由於 GDPR 要求採取能反映當前技術能力的措施,隨著加密標準、存取控制機制與監控能力的進步,您的合規基準也會隨之改變。
- 跨境傳輸的複雜性: 迄今為止,GDPR 單筆最高罰款針對的是不足的傳輸保障措施,而跨境資料流仍然是高風險領域,因為各司法管轄區對其處理方式不同。
- 人為錯誤占主導地位: 愛爾蘭 DPC 的 2024 年年度報告記載,人為錯誤是通報外洩事件的主要原因之一,包括郵寄資料與電子郵件寄送給錯誤收件人,這一點同樣見於 年度報告。在 EDPB 摘要中的一項執法案例顯示,監管機關否決僅有組織層面的措施,並要求額外的技術控制。成熟的 zero trust 存取與對外傳輸控制可降低日常錯誤的影響範圍。
- 持續文件化負擔: 第 5(2) 條的問責要求意味著文件化是一項持續性的營運要求。處理活動紀錄、DPIA、安全測試結果、外洩日誌與訓練紀錄都需要持續維護。
這些挑戰需要一套結構化的方法。以下最佳實務說明如何達成。
GDPR 安全要求最佳實務
以下每項實務都將監管義務對應到您的安全與合規團隊可共同執行的具體營運步驟。
1. 先建立風險評估基礎
在選擇任何安全控制之前,先完成有文件記錄的 GDPR 風險評估。 ENISA 手冊 關於個人資料處理安全性的內容強調,措施「依據 GDPR,應與所呈現的風險相稱」。盤點每一項處理活動、依敏感度分類資料,並評估風險發生的可能性與嚴重性。您的風險評估可為每一項安全決策提供依據,並在監管調查期間作為您的主要抗辯基礎。
2. 實施分層技術控制
部署具集中式金鑰管理的加密機制。對所有處理個人資料的系統強制實施以角色為基礎的存取控制,並搭配 multi-factor authentication。透過 SIEM、MDR 或 XDR 平台實施持續監控,以即時發現可疑活動。 ENISA 指南 建議記錄所有資料處理活動,以支援事件調查與問責要求。
3. 在外洩發生前就為 72 小時時限做好準備
專門圍繞 72 小時資料外洩通報要求來建立並測試您的事件回應計畫。定義升級程序、指派資料外洩評估角色,並與您的資料保護長(DPO)及法務團隊建立溝通鏈。EDPB 允許分階段通報,因此您的計畫應優先著重於快速的初步評估,而非完整調查。能夠在無需人工介入的情況下蒐集證據並重建攻擊時間軸的自主鑑識工具,可直接壓縮您的回應時限。
4. 透過具約束力的協議管理第三方風險
第 28 條要求與每個處理者簽訂資料處理協議。不要只停留在契約合規:依風險對供應商分級(處理的個人資料數量與敏感度、國際傳輸、次處理者鏈),並據此調整您的監控方式。
5. 持續文件化,而非定期文件化
將處理活動紀錄、DPIA、安全測試結果與外洩日誌視為動態文件。隨著處理活動變更而更新。第 33(5) 條要求您記錄所有外洩事件,包括您判定無需通報的事件。當監管機關展開調查時,這種持續文件化就是您的合規證據。
6. 針對人為錯誤進行訓練,而不只是網路攻擊
當大量通報的資料外洩事件來自作業失誤時,您的訓練計畫必須同時處理日常錯誤與外部攻擊。特定角色訓練、網路釣魚模擬,以及可防止常見錯誤的技術控制(例如 資料外洩防護(DLP) 規則攔截外寄電子郵件中的敏感資料)可共同降低最常見的資料外洩原因。
在定義最佳實務後,您需要一份實用的檢查清單,以追蹤整個組織的實作情況。
GDPR 安全合規檢查清單
使用此檢查清單評估您目前的安全態勢,並找出核心合規領域中的缺口。將其視為可每季執行一次,並在重大架構變更後進行的營運審查。
- 技術控制(第 32 條):確認處理個人資料的系統具備加密、最小權限存取、監控、經測試的備份,以及定期控制驗證。
- 組織控制(第 24、25、32 條): 保持政策、DPIA、第 30 條紀錄、訓練證據,以及第 25 條設計決策為最新且可供審查。
- 事件回應(第 33、34 條): 驗證角色、升級路徑、資料外洩記錄與證據擷取,以便您能及時做出通報決策。
- 供應商與傳輸(第 28 條): 確保 DPA、次處理者監督與傳輸評估符合您的實際處理情況,而不是去年的圖表。
如果您能以證據證明每個領域,您就具備可辯護的合規基準。接下來,您需要一個可統一保護、調查、鑑識與回應的平台。

Unleash AI-Powered Cybersecurity
Elevate your security posture with real-time detection, machine-speed response, and total visibility of your entire digital environment.
重點整理
GDPR 第 25 與第 32 條下的安全要求規定的是以風險為基礎的技術與組織措施,而非固定的技術檢查清單。您的合規性取決於有文件記錄的風險評估、加密、存取控制、持續監控,以及在 72 小時內回應資料外洩事件的能力。
執法是真實存在且正在加速,尤其是在備受矚目的資料外洩與傳輸案件之後。可統一保護、鑑識與回應的自主平台,能直接因應使 GDPR 合規在營運上變得困難的速度、可視性與文件記錄挑戰。
常見問題
GDPR 安全要求是《一般資料保護規則》第 25 與第 32 條要求任何處理 EU/EEA 個人資料的實體必須採取的技術與組織措施。第 32 條涵蓋加密、存取控制、系統韌性、及時資料還原,以及定期安全測試。
第 25 條則增加了設計與預設的資料保護。這些義務是以風險為基礎:您需選擇與您的處理情境相稱的控制措施、記錄其理由,並持續測試您的措施。
第 32 條著重於保護處理活動:加密、存取控制、韌性、還原能力,以及定期控制評估。第 25 條著重於您如何建置系統:設計與預設的資料保護、資料最小化,以及從第一天起即採用隱私友善設定。
在實務上,第 25 條驅動架構選擇與防護欄,而第 32 條則驗證您的日常控制是否持續符合已記錄的風險,而不只是符合您的原始意圖。
GDPR 對技術保持中立:它要求根據風險採取「適當」的安全措施,而不是固定的工具清單。也就是說,第 32 條明確將加密與假名化列為適當措施的範例。如果您大規模處理敏感資料,監管機關通常會期待強式加密、存取治理,以及支援事件調查的記錄。
您的責任是記錄為何您選擇的控制措施符合您的處理情境、威脅環境與「現有技術水準」。
72 小時計時從您知悉個人資料外洩事件時開始。EDPB 將「知悉」界定為對個人資料已遭洩露達到合理程度的確定性,而不只是注意到可疑活動。
您可以在 72 小時內提交分階段通報,並於稍後補充細節。重點在於證明您已迅速採取行動、擷取證據、記錄決策路徑,並在事實逐漸明朗時避免無正當理由的延遲。
第 32(1)(d) 條要求建立定期測試、評估與衡量安全有效性的流程,但並未規定固定時程。您的頻率應反映資料敏感度、處理規模與變更速度。
ENISA 建議高風險環境每季進行滲透測試,但您也應在重大版本發布或基礎架構變更後,驗證備份、還原程序、存取控制與記錄品質。 桌上演練 有助於證明您的 72 小時工作流程能在壓力下正常運作。
不能。政策、訓練與保密協議固然必要,但無法取代技術防護措施。監管機關通常會評估您是否使用了符合風險概況的可用技術控制,尤其是在存取管理、加密與記錄方面。
如果您只依賴程序性控制,即使員工大多數時間都遵循政策,您仍可能被認定您的措施並非「適當」。請使用文件記錄來說明人員與控制如何共同運作。


