关于 building-purpose-limitation-enforcement
面向数据保护与工程团队的 GDPR 目的限制实施指南,说明如何按处理目的标记数据、控制访问并评估用途兼容性。结合 OPA 策略和 Article 6(4) 因素描述执行流程。
主要功能
- 01数据采集时绑定处理目的
- 02按目的实施访问控制
- 03记录目的授权访问审计轨迹
- 04按 Article 6(4) 评估用途兼容性
- 05使用 OPA 编写策略
适用场景
- 01限制服务访问不匹配目的的数据
- 02审核将数据用于新目的的请求
- 03追踪目的标签覆盖与评估状态
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ mukul975/ privacy-data-protection-skills --skill building-purpose-limitation-enforcement安装后在 Claude Code 中输入/building-purpose-limitation-enforcement确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
assets/template.mdreferences/standards.mdworkflows.mdscripts/process.py详细介绍
构建目的限制执行机制
概述
GDPR 第 5(1)(b) 条要求,个人数据应“为特定、明确且合法的目的而收集,且不得以与这些目的不相容的方式进一步处理”。这就是目的限制原则,是数据保护的基本原则之一。
控制者必须在收集时或之前明确目的(直接收集适用第 13(1)(c) 条,间接收集适用第 14(1)(c) 条)。后续为不同目的进行的任何处理,都需要新的合法依据,或者必须通过第 6(4) 条规定的兼容性评估。
第 29 条工作组关于目的限制的第 03/2013 号意见(WP203)提供了兼容性评估的详细指南,并确定了第 6(4) 条所编纂的五项关键因素。
第 6(4) 条兼容性评估因素
当控制者希望为不同于收集个人数据时所声明的目的而处理个人数据时,第 6(4) 条要求评估兼容性,并考虑以下因素:
| 因素 | 第 6(4) 条引用 | 评估问题 |
|---|---|---|
| 目的之间的关联 | 第 6(4)(a) 条 | 原始目的与新目的之间是否存在关联? |
| 收集背景 | 第 6(4)(b) 条 | 控制者与数据主体之间是什么关系?数据主体有何合理预期? |
| 数据性质 | 第 6(4)(c) 条 | 数据是否包含特殊类别数据(第 9 条)或刑事定罪数据(第 10 条)? |
| 后果 | 第 6(4)(d) 条 | 进一步处理可能对数据主体造成哪些后果? |
| 保障措施 | 第 6(4)(e) 条 | 是否采取了适当的保障措施,包括加密或假名化? |
以下情况无需进行兼容性评估:
- 处理基于同意(第 6(1)(a) 条)——可针对新目的获取新的同意
- 处理基于欧盟或成员国法律,且该法律构成必要且相称的措施(第 6(4) 条最后一段)
- 根据第 89(1) 条,为公共利益归档、科学或历史研究,或统计目的进行处理
按目的标记的数据架构
设计原则
- 在数据录入时绑定目的 — 每条数据记录在进入系统时都会标记其收集目的
- 基于目的的访问控制 — 按目的定义访问策略,而非仅按数据字段定义
- 目的审计跟踪 — 每次访问都会记录其获准使用的目的
- 目的到期 — 目的实现后,相关数据将开始进入保留期限倒计时
架构图
┌────────────────────────────────────────────────────────────┐
│ Data Collection Points │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Web Form │ │ API Call │ │ IoT Feed │ │ Partner │ │
│ │ P:ONBRD │ │ P:ANALYT │ │ P:MAINT │ │ P:MARKET │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ └──────────────┼──────────────┼──────────────┘ │
└──────────────────────┼──────────────┼──────────────────────┘
│ │
┌──────────────────────▼──────────────▼──────────────────────┐
│ Purpose Tagging Gateway │
│ ┌─────────────────┐ ┌─────────────────────────────────┐ │
│ │ Purpose Registry │ │ Tag Injection Middleware │ │
│ │ (canonical IDs) │ │ (attaches purpose + timestamp) │ │
│ └─────────────────┘ └─────────────────────────────────┘ │
└──────────────────────────────┬─────────────────────────────┘
│
┌──────────────────────────────▼─────────────────────────────┐
│ Purpose-Partitioned Data Store │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ ONBRD │ │ ANALYT │ │ MAINT │ │ MARKET │ │
│ │ Partition│ │ Partition│ │ Partition│ │ Partition│ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
└──────────────────────────────┬─────────────────────────────┘
│
┌──────────────────────────────▼─────────────────────────────┐
│ Purpose Enforcement Layer │
│ ┌─────────────────┐ ┌────────────────┐ ┌────────────┐ │
│ │ Policy Engine │ │ Compatibility │ │ Audit │ │
│ │ (OPA / Cedar) │ │ Assessor │ │ Logger │ │
│ └─────────────────┘ └────────────────┘ └────────────┘ │
└────────────────────────────────────────────────────────────┘
目的注册表架构
每项处理目的都以规范的元数据进行登记:
{
"purpose_id": "PRP-ONBRD-001",
"purpose_name": "Customer Account Onboarding",
"description": "Collection and processing of personal data necessary to create and activate a customer account, verify identity, and establish the contractual relationship.",
"lawful_basis": "Article 6(1)(b)",
"data_categories": ["email", "display_name", "country_code", "identity_verification_result"],
"controller": "Prism Data Systems AG",
"retention_period_days": 2555,
"retention_trigger": "account_closure",
"compatible_purposes": ["PRP-SUPRT-001", "PRP-SECUR-001"],
"incompatible_purposes": ["PRP-MARKET-001", "PRP-RESRCH-001"],
"special_categories": false,
"created_date": "2025-06-01",
"last_reviewed": "2026-01-15",
"review_cadence_days": 180,
"owner": "product_team",
"dpo_approved": true
}
按目的进行访问控制
使用 Open Policy Agent(OPA)实现策略即代码
基于目的的访问控制通过 OPA 策略实现,这些策略会根据目的注册表评估访问请求:
# Prism Data Systems AG — Purpose-Based Access Policy
# Rule: Access is granted only if the requesting service's declared purpose
# matches a purpose tag on the requested data record.
allow {
input.action == "read"
input.resource.purpose_tags[_] == input.requester.declared_purpose
purpose_is_active(input.requester.declared_purpose)
role_authorized_for_purpose(input.requester.role, input.requester.declared_purpose)
}
# Rule: Cross-purpose access requires a completed compatibility assessment
allow {
input.action == "read"
not input.resource.purpose_tags[_] == input.requester.declared_purpose
compatibility_assessment_approved(input.resource.purpose_tags, input.requester.declared_purpose)
purpose_is_active(input.requester.declared_purpose)
}
# Rule: Write operations must include a valid purpose tag
allow {
input.action == "write"
valid_purpose(input.resource.purpose_tag)
input.requester.declared_purpose == input.resource.purpose_tag
}
角色-目的授权矩阵
| 角色 | ONBRD | ANALYT | SUPRT | MARKET | SECUR | BILLING |
|---|---|---|---|---|---|---|
| 入职服务 | 读取/写入 | — | — | — | — | — |
| 分析流水线 | — | 读取 | — | — | — | — |
| 支持 Agent | 读取 | — | 读取/写入 | — | — | 读取 |
| 营销自动化 | — | — | — | 读取 | — | — |
| 安全运营 | 读取 | 读取 | 读取 | 读取 | 读取/写入 | 读取 |
| 计费服务 | 读取 | — | — | — | — | 读取/写入 |
目的兼容性评估工作流
-
提交请求 — 服务负责人提交请求,申请将根据目的 A 收集的数据用于新的目的 B,并说明业务理由。
-
因素分析 — 数据保护办公室评估第 6(4) 条的五项因素:
- 目的之间的关联(评分 1-5:1 = 无关联,5 = 密切相关)
- 背景和预期(评分 1-5:1 = 出乎意料,5 = 完全符合预期)
- 数据性质(评分 1-5:1 = 特殊类别,5 = 非敏感)
- 后果(评分 1-5:1 = 严重,5 = 影响极小)
- 保障措施(评分 1-5:1 = 无保障措施,5 = 全面保障)
-
评分 — 计算总分(范围为 5-25):
- 20-25:兼容。批准,并提供标准文档记录。
- 15-19:可能兼容。批准,但需采取额外保障措施(假名化、访问限制)。
- 10-14:可能不兼容。需升级至 DPO 处理,并考虑进行 DPIA。
- 5-9:不兼容。拒绝。需有新的合法依据或单独同意。
-
记录决定 — 将评估结果记录在目的注册表中,包括评估人员身份、日期、评分明细、条件和复核日期。
-
更新策略 — 如果获批,则更新 OPA 策略,以允许在有记录的条件下跨目的访问。
Prism Data Systems AG 的实施
目的注册表
Prism Data Systems AG 在其目的注册表中维护 14 个已登记目的:
| 目的 ID | 名称 | 合法依据 | 数据类别 |
|---|---|---|---|
| PRP-ONBRD-001 | 客户注册 | Art. 6(1)(b) | email, display_name, country_code |
| PRP-AUTH-001 | 身份验证 | Art. 6(1)(b) | email, password_hash, mfa_token |
| PRP-BILLING-001 | 账单和发票 | Art. 6(1)(b) | billing_address, payment_method, vat_id |
| PRP-SUPRT-001 | 客户支持 | Art. 6(1)(b) | email, display_name, support_ticket_history |
| PRP-ANALYT-001 | 产品分析 | Art. 6(1)(f) | pseudonymized_user_id, feature_events, session_duration |
| PRP-MARKET-001 | 直接营销 | Art. 6(1)(a) | email, display_name, marketing_preferences |
| PRP-SECUR-001 | 安全监控 | Art. 6(1)(f) | ip_address, user_agent, login_events |
| PRP-LEGAL-001 | 法律合规 | Art. 6(1)(c) | transaction_records, consent_records |
执行指标
Prism Data Systems AG 跟踪以下目的限制执行指标:
| 指标 | 目标 | 衡量方式 |
|---|---|---|
| 目的标签覆盖率 | 100% 的记录 | 带有有效目的标签的数据记录所占比例 |
| 被拦截的跨目的访问尝试 | 未经评估的请求中 > 95% | 策略引擎拒绝次数与跨目的请求总数之比 |
| 已完成的兼容性评估 | 100% 在 5 个工作日内完成 | 从提交请求到 DPO 作出决定的时间 |
| 目的注册表复核及时率 | 100% 按周期完成复核 | 在各自复核周期内完成复核的目的所占比例 |
主要法规参考
- GDPR 第 5(1)(b) 条 — 目的限制原则
- GDPR 第 6(4) 条 — 兼容性评估因素
- GDPR 第 13(1)(c) 条 — 收集时告知目的
- GDPR 第 14(1)(c) 条 — 间接收集时告知目的
- GDPR 第 89(1) 条 — 档案保存、研究和统计的例外
- GDPR 序言第 50 条 — 进一步处理的兼容性
- 第 29 条工作组关于目的限制的第 03/2013 号意见(WP203)
- EDPB 关于第 25 条「通过设计和默认实现数据保护」的第 4/2019 号指南