Privacy by Design：設計原則

1）為什麼需要（目的和領域）

PbD確保默認產品中嵌入隱私而不是頂部「粘貼」。對於iGaming來說，它可以降低監管風險（GDPR/ePrivacy/本地法律），保護弱勢用戶，增強信任並降低事件成本。覆蓋範圍：web/mobile，KYC/AML/RG，支付，營銷/CRM，分析/DWH，logi/ARM，合作夥伴/供應商。

2）七項原則（以及如何在行動中降落）

1.主動性，非反應性

在發現階段進行威脅建模（LINDDUN/STRIDE）。
Jira/PR模式中的隱私接受標準。

2.默認隱私（Privacy by Default）

所有營銷/個性化撥號器-關閉，直到達成協議。
僅收集「嚴格要求」默認標識符。

3.隱私嵌入到設計中

PII存儲在區域回路（數據駐留）中，控制平面存儲在PII中。
服務事件中的密鑰令牌/別名化。

4.完整功能（win-win）

「匿名分析」和「同意個性化」模式。
平等的UX，不歧視拒絕跟蹤的人。

5.通過生命周期實現安全

在rest/in transit加密；BYOK/HYOK;網絡分割；秘密管理。
用於證據和審計的WORM期刊。

6.透明度

簡短的策略和「摘要框」關鍵條件；個人資料中的隱私面板。
報告：誰/什麼/何時/為什麼可以訪問數據。

7.面向用戶

簡單的文本，沒有深色模式，WCAG AA+可用性。
方便的同意反饋和方便的DSAR渠道。

3）角色和RACI

DPO/法規遵從性-PbD政策，DPIA/TRA，風險控制。(A)

Security/Infra Lead-密碼學，訪問，日誌，供應商。(R)

產品/UX-熟食店中的隱私要求，沒有黑暗模式。(R)

工程/體系結構-令牌化，tenant/region隔離，API合同。(R)

Data/Analytics-de-PII流水線,PETs,聚合。(R)

法律是法律依據，文本和地方。(C)

Marketing/CRM-同意/支持，誠實的溝通。(R)

內部審計-工件樣本，CAPA。(C)

4）數據分類和分類

PII基本：FIO，電子郵件，電話，地址，出生日期，IP/ID設備。
敏感PII：生物識別（自拍/生存），KYC文件，付款詳細信息，RG/SE狀態。
操作：遊戲事件,logi/traces（默認情況下為無PII）。
營銷/分析：cookies/SDK ID（經同意）。

規則：最小化，分離存儲，明確目的和保留期。

5）數據生命周期（Data Lifecycle）

1.收集只是必要的字段；SMR/同意；年齡檢查。
2.傳輸是TLS 1。2 +/mTLS，webhook簽名，區域路由。
3.存儲-加密、令牌化、密鑰旋轉、市場隔離。
4.用法是RBAC/ABAC，「需要知道」，用於分析的PET。
5.交換-DPA/SCC，最小集合，可審核通道。
6.Retence/Remove-按類別排列的期限；級聯刪除喬布；加密刪除檔案。
7.報告/審計-訪問和導出日誌,DPIA/DSAR工件。

6）DPIA/TRA（如何簡短）

觸發因素：新的PII類別，特殊類別，新供應商，跨境轉移，高風險的RG/生物識別。
DPIA模板：目標→數據類別→法律依據→流/映射→風險→措施（tes/org） →剩余風險→解決方案。
工件：線程圖，字段列表，風險表，批準協議。

7） PbD建築模式

Tenant/Region Isolation：物理/邏輯數據庫隔離，密鑰和秘密。
控制vs數據平面：全球控制-無PII；PII僅在本地。
De-PII管道：在出口到DWH之前-哈希/鹽，截斷，k 匿名/cohoration。
Tokenization Gateway：代幣代替服務總線中的主ID。
Edge no PII：CDN/edge緩存-僅公開內容。
Fail-Closed：未知的「player_region」 →禁止PII操作。

8）技術措施和標準

加密： AES-256/GCM at rest；TLS 1.2+/1.3;PFS.

鍵：KMS，BYOK/HYOK，輪換，HSM角色訪問，關鍵操作日誌。
訪問：RBAC/ABAC，JIT訪問，分離管理角色和審計角色。
期刊：不可變（WORM），哈希鏈，區域存儲。
DevSecOps：Vault的秘密，SAST/DAST，linter PII字段，CI的隱私測試。
測試數據：默認合成；如果re-department是de標識和簡短的回避。

9) PETs (Privacy-Enhancing Technologies)

別名：用令牌替換ID；Key-Map是單獨存儲的。
匿名：聚合，k- anonimnost/ℓ-多元化，bining/cohorts。
差分隱私：報告上的噪音，「privacy budget」。
聯合分析：局部模型,僅輸出權重/聚合物。
掩碼/修訂版本：刪除EXIF,在KYC文檔中設置字段。

10）沒有黑暗模式的UX

「拒絕全部「/「接受全部「/「自定義」的同等可見性。
可理解的目標文本和數據使用的示例。
拒絕個性化不會損害基本體驗。
1-2點擊的隱私面板；AA+的可用性。

11）供應商和數據傳輸

供應商註冊表：DC轄區，子處理器，認證，存儲區域，DPA/SCC/IDTA。
「最低設置」策略：只有正確的字段,禁止自由出口。
更改位置/子處理器時通知和修訂。

12）數據和事件（最小模型）

data_asset{id, category{KYC    PCI    RG    CRM    LOG    ANON}, region, owner, retention_days, lawful_basis, pii{yes/no}}
processing_event{id, actor, purpose, lawful_basis, started_at, ended_at, records_count, export{yes/no, basis_id}}
access_log{id, subject_id_hash, actor, action{read/write/export/delete}, ts_utc, reason, ticket_id}
erasure_job{id, subject_id_hash, scope, started_at, completed_at, evidence_id}

13） KPI/KRI和dashboard PbD

PII最小化指數（每個字節的平均PII字段數）。
Residency Coverage（在正確區域中記錄的百分比）。
出口保證率（參考基礎的出口數量）。
DSAR SLA（執行中位/精度）。
Tag Firing Violations（未經同意的標簽）。
Auditability Score（具有完整工件包的案例的百分比）。
Incidents/Findings（重復的審計/監管評論）。

14）支票單

A. fici開發前（設計）

• 確定了處理目的和法律依據。
• 數據圖和標有PII/敏感字段的列表。
• DPIA/TRA執行；接受殘余風險。
• 考慮了「匿名模式」或具有最小數據模式。

B.發布前（構建/發布）

• 管理員中的秘密,密碼/加密配置。
• 沒有PII的Logi；包括事件和審計。
• 區域路由和保留政策是活躍的。
• 測試：consent-gate, deny-by-default標簽,erasure路徑。

C.在操作中

• 季度的供應和出口評論。
• 監測火災違規和跨境查詢。
• DSAR/刪除按時執行；文物被保存。

15）模板（快速插入）

A）DPIA模板（簡稱）

B）字段最小化策略

C） Clause with vendor （PbD承諾）

D）對DSAR的響應（摘錄）

16）頻繁的錯誤以及如何避免錯誤

「以防萬一」收集。→最小化策略+修改電路代碼。
APM中帶有PII的原始日誌。→代理上的蒙面/編輯，本地存儲。
帶有PII的全球DWH。→僅de-PII聚合/別名。
沒有DPIA/consent工件。→ WORM存儲庫、UI自動快照/文本。
未註冊的供應商/SDK。→季度註冊表，禁止「灰色」連接。

17）30天實施計劃

第一周

1.批準PbD策略和DPIA/TRA模板。
2.在關鍵區域（KYC/PCI/RG/CRM/Logi）上構建數據/流映射。
3.劃定區域邊界（EU/UK/……）；定義密鑰模型（BYOK/HYOK）。

第二周

4） 啟用標記化/de-PII流水線和標記的deny-by-default。
5）設置WORM日誌（訪問/導出/同意/刪除）。
6）更新供應商合同（DPA/SCC，位置，子處理器）。

第3周

7）在CI中實施隱私測試（linter PII，CMP屏幕定位，erasure-E2E）。
8）配置文件中隱私面板的發布；改進文本和位置。
9）進行團隊培訓（Product/Eng/Data/CS/Legal）。

第四周

10）進行DPIA頂級比賽，關閉CAPA。
11）運行KPI/KRI（Residency，Exports，DSAR SLA）行車記錄儀。
12）計劃v1。1：diff。報告的隱私，聯邦管道。

18）相互關聯的部分

GDPR： 用戶同意管理/Cookie和CMP政策

跨轄區數據本地化

年齡檢查和年齡過濾器

AML/KYC和文物存儲

Dashboard complians和監控/監管報告

內部/外部審計和審計清單

BCP/DRP/加密恢復和運輸