关于GDPR

GDPR 详解

1. 定义

GDPR (General Data Protection Regulation，通用数据保护条例) 是欧盟于 2018 年 5 月 25 日正式生效的数据保护法规，被认为是全球最严格的隐私和数据保护法律。

1	GDPR = 欧盟公民个人数据保护的"黄金标准"

2. 核心概念

2.1 关键术语

术语	英文	定义
个人数据	Personal Data	任何可识别自然人的信息
数据主体	Data Subject	个人数据所属的自然人
数据控制者	Data Controller	决定数据处理目的和方式的实体
数据处理者	Data Processor	代表控制者处理数据的实体
处理	Processing	对数据的任何操作（收集、存储、使用、删除等）
DPO	Data Protection Officer	数据保护官
DPA	Data Protection Authority	数据保护监管机构

2.2 个人数据的范围

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

个人数据类型: ┌─────────────────────────────────────────────────────────────┐ │ │ │ 基本身份信息 │ │ ├── 姓名 │ │ ├── 身份证号 │ │ ├── 地址 │ │ └── 电话号码 │ │ │ │ 在线标识符 │ │ ├── IP 地址 │ │ ├── Cookie ID │ │ ├── 设备 ID │ │ └── 位置数据 │ │ │ │ 敏感数据 (特殊类别，需更严格保护) │ │ ├── 种族/民族 │ │ ├── 政治观点 │ │ ├── 宗教信仰 │ │ ├── 健康数据 │ │ ├── 性取向 │ │ ├── 基因数据 │ │ └── 生物特征数据 │ │ │ └─────────────────────────────────────────────────────────────┘

3. 适用范围

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

GDPR 适用于: ┌─────────────────────────────────────────────────────────────┐ │ │ │ 地域范围 (域外效力): │ │ ├── 在欧盟境内设立机构的组织 │ │ └── 虽不在欧盟，但满足以下条件之一: │ │ ├── 向欧盟居民提供商品或服务 │ │ └── 监控欧盟居民的行为 │ │ │ │ 示例: │ │ ├── 中国电商网站向欧洲销售商品 → 适用 │ │ ├── 美国 APP 有欧洲用户 → 适用 │ │ └── 仅服务中国用户的中国公司 → 不适用 │ │ │ └─────────────────────────────────────────────────────────────┘

4. 七大数据处理原则

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

GDPR 数据处理原则: ┌─────────────────────────────────────────────────────────────┐ │ │ │ 1. 合法性、公平性、透明性 (Lawfulness, Fairness, │ │ Transparency) │ │ └── 数据处理必须合法、公正，并对数据主体透明 │ │ │ │ 2. 目的限制 (Purpose Limitation) │ │ └── 数据只能用于收集时声明的特定目的 │ │ │ │ 3. 数据最小化 (Data Minimisation) │ │ └── 只收集必要的数据，不过度收集 │ │ │ │ 4. 准确性 (Accuracy) │ │ └── 确保数据准确，及时更新或删除不准确的数据 │ │ │ │ 5. 存储限制 (Storage Limitation) │ │ └── 数据保留时间不超过必要期限 │ │ │ │ 6. 完整性和保密性 (Integrity and Confidentiality) │ │ └── 采取适当安全措施保护数据 │ │ │ │ 7. 问责制 (Accountability) │ │ └── 数据控制者必须能够证明合规 │ │ │ └─────────────────────────────────────────────────────────────┘

5. 数据处理的合法性基础

处理个人数据必须至少满足以下一项合法性基础：

合法性基础	说明	常见场景
同意	数据主体明确同意	营销邮件订阅
合同履行	为履行与数据主体的合同	电商订单处理
法律义务	法律要求的处理	税务报告
重大利益	保护数据主体或他人的重大利益	紧急医疗救治
公共任务	为公共利益执行任务	政府服务
合法利益	控制者或第三方的合法利益	欺诈防范（需平衡测试）

1 2 3 4 5 6

同意的要求 (最常用但最严格): ├── 自由给予 (Freely given) - 不能强迫 ├── 具体明确 (Specific) - 针对特定目的 ├── 知情同意 (Informed) - 清楚告知用途 ├── 明确表示 (Unambiguous) - 积极行动表示同意 └── 可随时撤回 (Withdrawable) - 撤回与同意一样容易

6. 数据主体的八大权利

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

数据主体权利: ┌─────────────────────────────────────────────────────────────┐ │ │ │ 1. 知情权 (Right to be Informed) │ │ └── 了解数据如何被收集和使用 │ │ │ │ 2. 访问权 (Right of Access) │ │ └── 获取自己被处理的个人数据副本 │ │ │ │ 3. 更正权 (Right to Rectification) │ │ └── 要求更正不准确或不完整的数据 │ │ │ │ 4. 删除权/被遗忘权 (Right to Erasure / Right to be │ │ Forgotten) │ │ └── 要求删除个人数据 │ │ │ │ 5. 限制处理权 (Right to Restriction of Processing) │ │ └── 要求限制数据处理 │ │ │ │ 6. 数据可携权 (Right to Data Portability) │ │ └── 以可机读格式获取数据，并转移给其他控制者 │ │ │ │ 7. 反对权 (Right to Object) │ │ └── 反对某些类型的数据处理（如直接营销） │ │ │ │ 8. 自动化决策相关权利 (Rights related to Automated │ │ Decision-making) │ │ └── 不受仅基于自动化处理的决策影响，要求人工干预 │ │ │ └─────────────────────────────────────────────────────────────┘ 响应时限: 收到请求后 1 个月内响应 (可延长至 3 个月)

7. 企业合规义务

7.1 主要合规要求

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

GDPR 合规要求: ┌─────────────────────────────────────────────────────────────┐ │ │ │ 透明度与告知 │ │ ├── 提供清晰的隐私政策 │ │ ├── 告知数据收集目的 │ │ ├── 说明数据保留期限 │ │ └── 告知数据主体权利 │ │ │ │ 数据保护设计 (Privacy by Design) │ │ ├── 在系统设计阶段就考虑隐私保护 │ │ ├── 默认隐私设置 │ │ └── 数据最小化原则 │ │ │ │ 数据处理记录 (ROPA) │ │ ├── 记录所有数据处理活动 │ │ └── 包括目的、类别、接收方、保留期限等 │ │ │ │ 数据保护影响评估 (DPIA) │ │ ├── 高风险处理活动前必须进行 │ │ └── 评估对数据主体权利的影响 │ │ │ │ 数据保护官 (DPO) │ │ ├── 某些情况下必须任命 │ │ │ ├── 公共机构 │ │ │ ├── 大规模系统性监控 │ │ │ └── 大规模处理敏感数据 │ │ └── 负责监督 GDPR 合规 │ │ │ │ 数据泄露通知 │ │ ├── 72 小时内通知监管机构 │ │ └── 高风险泄露需通知受影响个人 │ │ │ │ 跨境数据传输 │ │ ├── 充分性认定国家（如日本、韩国、英国） │ │ ├── 标准合同条款 (SCCs) │ │ ├── 约束性公司规则 (BCRs) │ │ └── 数据主体明确同意 │ │ │ └─────────────────────────────────────────────────────────────┘

7.2 隐私政策要求

1 2 3 4 5 6 7 8 9 10 11 12 13 14

隐私政策必须包含: ├── 数据控制者身份和联系方式 ├── DPO 联系方式（如有） ├── 收集的数据类型 ├── 数据处理目的 ├── 处理的法律依据 ├── 数据接收方/共享对象 ├── 跨境传输情况 ├── 数据保留期限 ├── 数据主体权利 ├── 撤回同意的方式 ├── 向监管机构投诉的权利 ├── 是否存在自动化决策 └── 数据来源（非直接收集时）

8. 处罚机制

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

GDPR 处罚分为两个层级: ┌─────────────────────────────────────────────────────────────┐ │ │ │ 较低层级 (最高 €10M 或全球年营收 2%，取较高者) │ │ 适用于: │ │ ├── 未维护处理记录 │ │ ├── 未任命 DPO（要求时） │ │ ├── 未进行 DPIA（要求时） │ │ └── 未通知数据泄露 │ │ │ │ 较高层级 (最高 €20M 或全球年营收 4%，取较高者) │ │ 适用于: │ │ ├── 违反数据处理原则 │ │ ├── 违反数据主体权利 │ │ ├── 非法跨境数据传输 │ │ └── 不遵守监管机构命令 │ │ │ └─────────────────────────────────────────────────────────────┘ 重大处罚案例: ├── Amazon: €7.46亿 (2021) - 广告定向违规 ├── WhatsApp: €2.25亿 (2021) - 透明度不足 ├── Google: €1.5亿 (2022) - Cookie 同意问题 ├── Meta/Facebook: €3.9亿 (2023) - 广告个性化 └── TikTok: €3.45亿 (2023) - 儿童隐私保护

9. GDPR 合规实施步骤

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

GDPR 合规实施路线图: ┌─────────────────────────────────────────────────────────────┐ │ │ │ 阶段1: 评估与规划 │ │ ├── 数据映射 (Data Mapping) │ │ │ └── 识别收集哪些数据、从哪里、用于什么 │ │ ├── 差距分析 │ │ │ └── 对比现状与 GDPR 要求 │ │ └── 制定合规计划 │ │ │ │ 阶段2: 政策与流程 │ │ ├── 更新隐私政策 │ │ ├── 建立同意管理机制 │ │ ├── 制定数据主体请求处理流程 │ │ ├── 建立数据泄露响应流程 │ │ └── 制定数据保留政策 │ │ │ │ 阶段3: 技术实施 │ │ ├── 实施同意管理平台 (CMP) │ │ ├── 实施数据主体请求系统 │ │ ├── 数据加密与安全措施 │ │ ├── 访问控制与日志审计 │ │ └── 数据删除/匿名化能力 │ │ │ │ 阶段4: 组织与培训 │ │ ├── 任命 DPO（如需） │ │ ├── 员工培训 │ │ └── 供应商/第三方管理 │ │ │ │ 阶段5: 持续合规 │ │ ├── 定期审计 │ │ ├── DPIA 评估 │ │ └── 持续监控与改进 │ │ │ └─────────────────────────────────────────────────────────────┘

10. 对支付/金融行业的影响

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

支付行业 GDPR 关注点: ┌─────────────────────────────────────────────────────────────┐ │ │ │ 数据收集 │ │ ├── 交易数据 (金额、时间、商户) │ │ ├── 身份验证数据 (KYC) │ │ ├── 支付凭证数据 (卡号、CVV - 注意 PCI DSS) │ │ └── 行为数据 (欺诈检测用) │ │ │ │ 合法性基础选择 │ │ ├── 合同履行: 处理支付交易 │ │ ├── 法律义务: AML/KYC 合规 │ │ ├── 合法利益: 欺诈防范 │ │ └── 同意: 营销、非必要的数据收集 │ │ │ │ 数据保留 │ │ ├── 交易记录: 通常因法规要求保留 5-7 年 │ │ ├── KYC 数据: 账户关闭后 5-10 年 │ │ └── 营销数据: 基于同意，可随时撤回 │ │ │ │ 跨境传输 │ │ ├── 卡组织网络 (跨境交易) │ │ ├── 云服务商 (数据存储) │ │ └── 第三方服务 (风控、分析) │ │ │ └─────────────────────────────────────────────────────────────┘

11. GDPR vs 其他隐私法规

法规	地区	生效时间	特点
GDPR	欧盟	2018	最严格、域外效力
CCPA/CPRA	美国加州	2020/2023	侧重消费者权利
LGPD	巴西	2020	类似 GDPR
PIPL	中国	2021	数据本地化要求
POPIA	南非	2021	非洲首个综合隐私法
PDPA	新加坡	2014	亚洲较早的隐私法

1 2 3 4 5 6 7 8 9 10 11

中国《个人信息保护法》(PIPL) 与 GDPR 对比: ├── 相似点 │ ├── 数据主体权利 │ ├── 合法性基础 │ ├── 数据保护影响评估 │ └── 跨境传输限制 │ └── 不同点 ├── PIPL 对跨境传输更严格（需安全评估或认证） ├── PIPL 数据本地化要求更强 └── PIPL 重要数据概念

12. 常用合规工具

类别	工具	用途
同意管理 (CMP)	OneTrust, Cookiebot, TrustArc	Cookie 同意、偏好管理
数据映射	OneTrust, BigID	数据发现与分类
DSR 管理	DataGrail, Transcend	数据主体请求处理
隐私影响评估	OneTrust, Nymity	DPIA 管理
数据脱敏	Delphix, Informatica	数据匿名化/假名化

13. 总结

GDPR 的核心价值观：

1	"将个人数据的控制权还给个人，让数据处理透明、可控、有限"

关键合规要点：

1. 知道你有什么数据 - 数据映射是基础
2. 有合法理由 - 每项处理都需要合法性基础
3. 最小化 - 只收集必要的，只保留必要的时间
4. 透明 - 清晰告知用户
5. 赋予权利 - 尊重数据主体的各项权利
6. 保护好 - 适当的安全措施
7. 能证明 - 保留合规证据

对支付系统的启示：

• 隐私设计融入系统架构
• 建立完善的数据生命周期管理
• 数据最小化与目的限制
• 跨境传输合规机制
• 数据主体权利实现能力

落地方案

按GDPR要求、支付业务数据敏感度、存取控制、跨境传输、留存与审计来组织一套可执行框架，并用权威来源核对关键点。进一步核对GDPR条文、欧盟SCC/跨境传输资料及反洗钱留存要求，并会把处理目的、合法性基础、跨境路径、留存期和权限绑定到数据目录。

下面按 EU GDPR 给一套适合跨境支付公司的落地方案。正式实施时，还要结合你们持牌地的金融监管、AML/KYC、税务/账务留存、PCI DSS、当地监管口径，由 DPO/法务确认。

1. 先定原则：GDPR不是只要“打标签”，而是要能证明“为什么处理、谁能看、留多久、传到哪里、怎么保护”

GDPR的核心不是规定固定的“几级数据”，而是要求个人数据处理具备合法性、目的限制、数据最小化、准确性、存储期限限制、完整性与保密性，并且公司要能证明这些要求已经落实；同时，第30条要求维护处理活动记录，记录处理目的、数据主体和个人数据类别、接收方、第三国传输、预计删除期限和安全措施；第32条要求按风险采取加密、假名化、可用性/韧性、定期测试等技术和组织措施。

因此，建议你们把数据治理做成三张表：数据分类分级表、数据处理活动记录 RoPA、访问权限矩阵。每个数据资产都要绑定：处理目的、合法依据、敏感等级、数据主体、系统位置、接收方、跨境传输机制、保存期限、访问角色、加密/脱敏/审计要求。

---

2. 建议的数据分级：5级即可，重点放在支付/KYC/风控场景

在GDPR下，匿名化和假名化要区分：真正匿名、不可再识别的数据通常不适用GDPR；但假名化数据如果能通过额外信息重新识别个人，仍应视为个人数据。GDPR还对特殊类别数据、犯罪定罪/违法相关数据设置更高限制；支付卡数据虽然不是GDPR单独定义的“特殊类别”，但支付行业还要并行满足PCI DSS等安全要求。

等级	定义	跨境支付公司典型数据	默认存取控制
L0 公开/匿名数据	公开资料，或经严格匿名化后无法识别个人的数据	聚合交易量、国家级成功率统计、公开汇率说明、匿名化运营报表	可用于分析和报表；仍要防止小样本重识别，例如“某小国家某天唯一一笔大额交易”
L1 内部业务数据	不直接涉及个人，但对公司运营敏感	路由规则、费率配置、清结算规则、系统配置、供应商合同非个人部分	内部访问；按部门和岗位控制；禁止公开泄露
L2 普通个人数据	可识别自然人的一般个人数据	姓名、邮箱、手机号、地址、客户ID、IP、设备ID、登录时间、客服工单基础信息	默认脱敏展示；客服、运营按工单/客户关系访问；批量导出需审批
L3 高敏金融/身份数据	泄露会导致金融欺诈、身份盗用或重大权益损害的数据	IBAN/银行卡账号或代币、交易金额/币种/收付款方、收款人信息、交易用途、KYC证件影像、地址证明、受益所有人信息、风险评分、设备指纹、制裁/PEP筛查结果	强加密、字段级脱敏、最小权限、JIT临时授权、全量审计；默认禁止进入日志、BI宽表和开发测试环境
L4 受限/特殊/强监管数据	特殊类别、犯罪/制裁相关、认证秘密、密钥、极高风险数据	生物识别模板或活体检测特征、可能揭示健康/宗教/政治/工会等信息的交易备注、犯罪定罪/违法相关记录、密码哈希、MFA种子、私钥、支付敏感认证数据	最高限制：隔离存储、双人审批、专用安全域、禁止批量导出、专门DPIA、密钥分离、异常访问告警

实践上，交易数据建议默认从L3起步。跨境支付交易不仅包含金额和账户，还可能通过交易对象、商户、用途、备注推断个人的医疗、宗教、政治捐赠、法律服务等敏感信息，所以不应按“普通业务流水”处理。

---

3. 按业务域分类：每类数据都要有“数据主人”和“合法依据”

GDPR第6条要求每项个人数据处理都有合法依据，例如履行支付合同、履行AML/KYC法律义务、合法利益下的反欺诈与系统安全，或在特定场景下基于同意。不要把“用户同意”当作所有处理的万能依据，尤其是支付履约、AML/KYC和法定留存通常不是靠同意来支撑。

数据域	典型内容	建议等级	常见处理目的	典型访问方
客户账户数据	姓名、联系方式、客户ID、账户状态	L2-L3	开户、登录、通知、客户服务	客服、合规、运营
KYC/AML数据	证件、地址证明、受益所有人、PEP/制裁/负面新闻筛查	L3-L4	客户尽调、持续监控、可疑交易调查	KYC、AML、法务、DPO
支付交易数据	收付款人、账户、金额、币种、时间、渠道、交易用途	L3-L4	执行支付、清结算、对账、争议处理、风控	支付运营、财务、风控、合规
支付卡/账户数据	PAN或代币、BIN、后四位、卡组织响应码	L3-L4	支付处理、退款、拒付处理	支付系统、少数支付运营人员
风控/反欺诈数据	设备指纹、IP、行为特征、规则命中、风险评分	L3-L4	欺诈检测、账户保护、交易拦截	风控、AML、模型团队
客服/争议数据	工单、聊天、邮件、通话录音、争议材料	L2-L3，可能L4	客户支持、投诉处理、退款/拒付	客服、争议处理、法务
安全与审计日志	登录日志、后台操作日志、API调用、访问审计	L2-L4	安全监控、取证、审计	安全、SRE、合规
数据分析/模型数据	报表、特征表、训练集、指标看板	L0-L3	经营分析、风控建模、服务优化	数据、风控、管理层

---

4. 数据“存”：存储架构要按敏感等级隔离

建议把生产数据拆成几个安全域，而不是全部放进一个大库或一个数据湖：

1. PII Vault / Identity Vault：存姓名、邮箱、手机号、证件号、地址等直接识别信息。业务系统只拿内部customer_id，不直接复制PII。
2. KYC Vault：证件影像、地址证明、活体检测结果、受益所有人资料单独存储，和普通账户库隔离。KYC影像不要进入客服截图、BI系统、普通数据湖。
3. Payment Ledger / Transaction Store：交易账本保留必要字段，但对收付款账户、卡号、IBAN、姓名做令牌化或字段级加密。财务对账可以访问金额、币种、交易号、结算状态，但不一定需要完整身份资料。
4. Risk Feature Store：风控模型尽量使用假名化ID、特征和统计值，不直接使用证件影像、完整姓名、完整账户号。模型训练数据要有独立DPIA和保留期限。
5. Analytics Warehouse：默认只放L0-L2或假名化后的L3数据。禁止把原始证件、完整银行账户、客服录音、原始交易备注、密码/MFA/密钥等复制到分析环境。
6. Logs & Observability：日志默认不得记录完整PII、证件号、完整账户号、token、Authorization header、密码、MFA种子、私钥。对URL参数、请求体、错误堆栈做自动脱敏。
7. Backups：备份继承源数据最高等级。备份也要加密、分区、设保留期，并能支持删除/到期销毁策略；不能让备份成为“永久保留个人数据”的漏洞。

---

5. 数据“取”：用RBAC + ABAC + JIT，而不是只靠“部门权限”

GDPR第25条要求数据保护默认设置要限制处理范围、保存期限和可访问性；第32条要求访问与安全措施按风险设计。因此，后台系统不应默认让“客服/运营/技术”看到完整客户资料，而应按目的、工单、地区、角色、时间、数据等级动态授权。

建议权限模型：

角色	默认可见	默认不可见	高风险操作
客服一线	客户基础资料、交易状态、脱敏交易信息、工单历史	完整证件影像、完整账户号、风险模型细节、制裁命中详情	查看更多信息需绑定工单、说明目的、短时授权
KYC审核	KYC资料、证件、地址证明、受益所有人、审核结果	支付密钥、工程日志、非相关客户交易全量数据	证件下载、批量导出、修改审核结论需审批和审计
AML/合规调查	交易网络、KYC、PEP/制裁、可疑交易线索	与案件无关的客户资料	案件制访问；批量查询、跨客户图谱导出需双人审批
风控/反欺诈	风险特征、设备/IP、规则命中、假名化交易数据	原始证件、完整联系方式、密钥	模型训练集导出、规则阈值变更需审批
财务/清结算	交易号、金额、币种、结算批次、费用、对账状态	KYC证件、客服录音、完整身份信息	异常退款、手工调账需双人复核
数据分析	聚合/匿名报表、假名化数据集	原始PII、证件影像、完整账户、原始备注	申请L3数据需DPIA/数据负责人审批
工程/SRE	系统健康、脱敏日志、指标、错误码	生产库明文PII、KYC影像、密钥	break-glass访问需MFA、审批、录屏/命令审计、自动过期
法务/DPO	与数据主体请求、监管、诉讼相关的数据	无关业务全量数据	调取证据需案件号、保留令、审计记录

关键控制项：

• 默认拒绝：没有明确处理目的和角色授权，就不能访问。
• 最小字段：能看后四位就不看全号，能看交易状态就不看交易备注。
• 按案件授权：KYC、AML、争议、投诉、法务场景都应绑定case_id。
• JIT临时权限：L3/L4数据访问按小时或天授权，到期自动回收。
• 强认证：后台、管理端、数据平台必须MFA；L4访问建议硬件密钥或强认证。
• 全量审计：记录谁、何时、因何目的、访问了哪个客户/字段、是否导出。
• 导出比查看更高风险：L3/L4导出单独审批、加水印、加密、DLP扫描、到期销毁。
• 禁止共享账号：所有后台操作必须可追溯到个人。
• 生产隔离：开发、测试、BI、模型环境不得直接复用生产明文数据。

---

6. 保存期限：不要“一刀切永久保留”

GDPR要求个人数据保存时间不得超过处理目的所必需的期限；第17条也要求在满足条件时删除，但在法律义务、公共利益、法律主张等情况下会存在例外。支付公司通常还受AML/KYC、账务、税务、争议、拒付、诉讼保全等保留义务约束，所以应做“按数据域的保留表”，而不是统一永久保存。

示例保留策略：

数据类型	建议策略
未完成注册资料	短期保留，例如30-90天；未转化则删除或匿名化
客户账户资料	账户存续期间保留；关闭后进入限制处理状态，仅为法定义务、争议、审计保留
KYC/AML资料	按适用AML法律保留；欧盟反洗钱规则中，客户尽调资料和交易记录通常涉及业务关系结束或偶发交易后的5年保留要求，具体以成员国落地法和新规适用时间为准。
交易账本	按支付、会计、税务、AML、争议/拒付期限设定；到期后删除直接识别字段或匿名化
风控特征/设备数据	以欺诈风险窗口为限；长期建模应使用假名化或聚合数据
客服录音/聊天	按投诉、争议和监管要求设置较短期限；含证件或敏感信息时应单独脱敏/删除
安全日志	为安全审计保留必要期限；避免日志里含明文PII，日志本身也要分级
备份	设置固定滚动周期；到期销毁；恢复后也要执行删除/限制处理逻辑

---

7. 跨境传输：把“第三国访问”也纳入管控

跨境支付公司最容易踩坑的是：数据没有“导出文件”，但客服、风控、云厂商、外包团队、集团总部、远程SRE从EEA外访问了生产个人数据。EDPB对第三国传输的判断强调：GDPR适用的出口方将个人数据传输或以其他方式提供给第三国的控制者/处理者时，会触发Chapter V的跨境传输要求。

跨境传输落地顺序：

1. 先做数据流图：EU/EEA客户数据从哪里采集、存在哪里、谁访问、复制到哪些国家、哪些供应商处理。
2. 优先使用充分性认定国家/地区：欧盟委员会维护充分性决定清单；例如美国仅限参与EU-US Data Privacy Framework的商业组织，具体要查供应商状态。
3. 没有充分性认定时使用SCC/BCR等工具：欧盟委员会说明SCC可作为EU到第三国传输的保障机制，并已发布现代化SCC。
4. 做Transfer Impact Assessment（TIA）：使用SCC不等于万事大吉，还要评估第三国法律和政府访问风险；EDPB的补充措施建议强调，在必要时识别并实施额外技术/组织/合同措施，以达到实质等同保护。
5. 技术上减少可读性：跨境支持优先用脱敏界面；跨境数据副本加密；密钥尽量留在EEA或受控区域；第三国团队不应能直接查询明文KYC和完整交易数据。
6. 供应商管理：云、KYC、制裁筛查、客服、邮件、监控、数据分析供应商都要签DPA；处理者只能按书面指示处理数据，并且分包处理者、删除/返还、审计、安全协助等要写进合同。

---

8. 自动化风控和AML评分：要做DPIA和人工复核机制

跨境支付公司的欺诈拦截、账户冻结、拒绝交易、关闭账户、提高审核等级等，可能对个人产生重大影响。GDPR第35条要求高风险处理前做DPIA，特别是自动化系统性评估、画像并产生重大影响的处理；第22条则限制仅基于自动化处理、且产生法律效果或类似重大影响的决定，并要求在适用场景下提供人工介入、表达意见和争议机制。

建议做法：

• 每个风控/AML模型建立 model card + DPIA + 合法依据记录。
• 明确哪些场景是“自动建议”，哪些是“自动决定”。
• 对账户冻结、交易拒绝、关闭账户等高影响动作设置人工复核或申诉通道。
• 记录模型输入字段，避免使用不必要的特殊类别数据。
• 定期做偏差、误杀率、可解释性和安全测试。
• 对客户隐私通知中说明存在欺诈检测、AML筛查和必要的自动化处理。

---

9. 组织治理：这些文件和流程必须齐

跨境支付公司通常涉及大规模、持续性的客户监控、KYC/AML和风控处理；在满足GDPR第37条情形时需要指定DPO，特别是核心活动包含大规模定期系统性监控，或大规模处理特殊类别/犯罪相关数据。

最低落地包建议包括：

1. 数据分类分级政策：定义L0-L4、例子、控制要求。
2. 数据资产目录：系统、表、字段、等级、owner、位置、数据主体、来源。
3. RoPA处理活动记录：目的、合法依据、数据类别、接收方、第三国传输、保存期限、安全措施。
4. 权限矩阵：角色、字段级权限、审批人、访问时长、导出规则。
5. 数据保留与删除政策：按账户、KYC、交易、日志、客服、备份分别设期限。
6. DPIA模板与台账：KYC、AML、风控评分、设备指纹、跨境传输、AI/模型训练优先纳入。
7. 供应商DPA和分包清单：KYC供应商、制裁筛查、云、客服、邮件、监控、数据平台。
8. 跨境传输台账：国家、接收方、数据类别、机制、SCC版本、TIA、补充措施。
9. 数据主体请求流程：访问、更正、删除、限制处理、反对、可携带、自动化决定申诉。
10. 安全事件响应流程：个人数据泄露时，控制者通常需在知悉后无不当延迟并尽可能72小时内通知监管机构，除非不太可能对个人权利自由造成风险。

---

10. 一个可执行的落地顺序

第一阶段：盘点和定级

先从生产系统、数据仓库、日志平台、客服系统、KYC供应商、制裁筛查供应商、云存储、BI、模型平台开始，列出所有数据资产。每个字段至少标注：数据域、等级、是否个人数据、是否特殊类别/犯罪相关/支付卡相关、处理目的、合法依据、保存期限、跨境位置、访问角色。

第二阶段：权限收敛

把后台权限从“部门可见”改成“角色 + 目的 + 案件 + 地区 + 时间”的组合授权。先收紧L3/L4：KYC影像、完整账户号、交易备注、风控评分、制裁命中、客服录音、原始日志、导出能力。

第三阶段：技术隔离

建立PII Vault、KYC Vault、交易账本、风控特征库、分析仓库的边界。所有跨系统调用走API，不允许随意复制明文字段。日志和数据湖做自动脱敏。

第四阶段：跨境和供应商整改

补齐DPA、SCC、TIA、分包处理者清单、跨境访问审批。对第三国客服、SRE、集团总部、外包团队先默认只能看脱敏数据。

第五阶段：审计和持续运营

每季度做权限复核、导出审计、异常查询审计、数据保留检查、DPIA复审。新增产品、国家、支付通道、KYC方式、风控模型、AI功能前，先走隐私评审。