# Dpa Art 28 Oliver Schmidt Prietz

> 审查、起草或修订 GDPR 第 28 条下的数据处理协议（DPA / Auftragsverarbeitungsvertrag / AVV），或起草 GDPR 第 26 条下的共同控制人安排。支持双语输出（德/英）、控制人侧与处理人侧双重视角，以及两种审查深度——快速（Art. 28(3)(a)–(h) 覆盖检查）与谈判级（逐条风险评分）。

- Skill: `cslawyer1985/dpa-art-28-oliver-schmidt-prietz` (Agent Skill, multi-file: 25 files)
- Install (CLI): `npx skillmds@latest add cslawyer1985/dpa-art-28-oliver-schmidt-prietz`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cslawyer1985/dpa-art-28-oliver-schmidt-prietz/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: cslawyer1985 (https://skillmd.com/u/cslawyer1985)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/cslawyer1985/dpa-art-28-oliver-schmidt-prietz

---


# DPA Art. 28 GDPR——审查、起草与修订

## 目的

本技能规范所有关于**控制人—处理人合同（GDPR 第 28 条）**和**共同控制人安排（GDPR 第 26 条）**的工作。其产出包括：

- 对现有 DPA 的**审查**（快速或谈判级）
- 基于模块化模板（德/英）**起草**新的 DPA / AVV
- 针对相对方草稿的**修订稿**（Redlines）
- **共同控制人协议**（JCA / Art.-26-Vereinbarung）

## 模式路由器——必须始终先行运行

在任何其他操作之前，将请求归类为以下模式之一：

| 模式 | 触发模式 | 工作流文件 |
|---|---|---|
| `REVIEW_QUICK` | “这份 DPA 是否合规？”、“Art. 28(3)(a)–(h) 检查”、短周期、需要签署/不签署决策 | `workflows/review-quick.md` |
| `REVIEW_NEG` | “为谈判审查此文件”、“给我修订要点”、“我们应该对哪些内容提出异议”、更深入的尽调 | `workflows/review-negotiation.md` |
| `DRAFT` | “起草一份 DPA”、“创建一份 AVV”、“我们需要一份针对 [X] 的处理人协议”、全新起草 | `workflows/draft.md` |
| `REDLINE` | 相对方已发送 DPA，用户希望得到修订追踪版/反提案 | `workflows/redline.md` |
| `JOINT_CONTROLLER` | “Art. 26”、“共同控制人”、“JCA”，或角色筛查显示为共同控制人而非处理人关系 | `workflows/joint-controller.md` |

**如不明确，请询问。** 不要在 `REVIEW_QUICK` 与 `REVIEW_NEG` 之间猜测——两者的深度差异约为 30 分钟对比 2–3 小时的分析工作量，且输出结构有实质性不同。

**工作过程中允许且预期会发生模式切换。** 如果 `REVIEW_QUICK` 揭示了足够严重、用户需要谈判指引的问题，应明示并提出升级为 `REVIEW_NEG`。如果在 `DRAFT` 或 `REVIEW_*` 过程中的角色筛查显示双方实际上是共同控制人，应停止并切换到 `JOINT_CONTROLLER`。

## 信息接收——在产出输出前必须始终收集以下内容

无论何种模式：

1. **角色**——谁是控制人，谁是处理人？明确确认。如果双方都可能是控制人，在继续之前先运行 `references/art26-joint-controller.md` 中的 Art. 26 与 Art. 28 筛查。
2. **视角**——用户代表哪一方？（偏控制人 / 偏处理人 / 平衡）
3. **语言**——德文 / 英文 / 双语？默认：与源文档语言一致；若从零起草，请询问。
4. **层级（DRAFT 与 REDLINE 模式）**——第 1 级商业型 / 第 2 级严格型（2021/915 原样并入）/ 第 3 级混合型（2021/915 第一、二部分 + 自定义第三部分）。若用户未预先选择，加载 `references/tier-selection.md` 并走决策树。对审查模式，层级即源文档本身的层级——识别后继续即可。
5. **处理场景**——具体描述：处理事项、处理性质、处理目的、数据类型、数据主体类别、处理期限。缺少这些，起草无法进行、审查也流于表面。如缺失，在继续前要求用户提供。
6. **国际传输**——个人数据是否将被传输至欧洲经济区（EEA）之外，或将从 EEA 之外访问？如是，尽早加载 `references/sccs-module-guide.md` 并标记 SCC 要求。注意：2021/915（第 2/3 级）本身不覆盖传输——如有需要，应与 2021/914 配套使用。
7. **子处理人**——一般性授权、特定授权，还是均无？这影响条款结构与风险概况。对第 2/3 级，这对应 SCC 条款 7.7 选项 1/2。
8. **特殊类别 / 第 9 条 / 第 10 条数据**——如涉及，需要强化版技术与组织措施（TOMs）和更严格的目的限制；在信息接收时标记。

## 硬性规则

- **未确认角色前，绝不产出 DPA 或审查意见。** 将控制人—控制人关系错误归类为控制人—处理人关系会产生无效协议，并给双方带来责任敞口。
- **绝不未经场景定制就逐字粘贴模板。** 附件 1（处理描述）必须反映实际处理情况——通用占位符使 Art. 28(3) 序言部分失效。
- **绝不遗漏附件 2（技术与组织措施 TOMs）。** 未明确 TOMs 的 DPA 违反 Art. 28(3)(c) 及第 32 条。如果用户尚无 TOMs，建议其取得处理人的 TOMs 文件或以模板骨架为起点，但须将此标记为未决事项——绝不为空白的附件 2 背书放行。
- **如存在子处理人，子处理人清单（附件 3）不得为空。** 仅当确实没有任何子处理人时，“签署时无”方可接受；否则须按名称、所在地、处理活动和安全保障措施逐一列明。
- **国际传输条款仅在 SCC 实际签署时才有约束力。** 不得在未明确模块、签署机制（单独签署 vs 通过 DPA 对接）及附件 I.A / I.B / I.C / II / III 的情况下起草“双方同意采用 SCC”。
- **共同控制人场景不是处理人场景。** 如果筛查标记为 JC，切换到 `JOINT_CONTROLLER` 模式。把 JC 安排写成 DPA 属于实质性缺陷，而非起草选择。
- **除非所有 Art. 28(3) 项目均为“通过”、范围内无传输，且用户理解剩余责任分配，否则绝不在快速审查后建议“按原样签署”。** 默认立场是“在记录剩余风险的情况下签署”或“要求修改”。
- **双语输出 ≠ 机器翻译。** 产出平行德/英文本时，德语侧使用德国法律语体（“der Verantwortliche”、“der Auftragsverarbeiter”、声明用“Sie”称呼形式），英语侧使用标准商业语体。不得从一侧反向翻译成另一侧。

## 参考文件加载顺序

进入任何模式时，按以下顺序加载文件：

1. **始终**——`references/art28-3-checklist.md`（Art. 28 要求的规范清单）。
2. **按模式**：
   - `REVIEW_QUICK` → 另加载工作流文件。仅此即可。
   - `REVIEW_NEG` → 另加载 `references/common-defects.md` + `references/negotiation-fallbacks.md`。如源草稿基于 2021/915，再加载 `references/2021-915-commission-text-{en,de}.md`（与语言匹配）。
   - `DRAFT` → 另加载 `references/tier-selection.md`（始终）；相关模板文件（`templates/dpa-{commercial,strict,hybrid}-{en,de}.md` 或 `templates/jca-{en,de}.md`）；如为第 2 级或第 3 级，另加载 `references/2021-915-commission-text-{en,de}.md`。
   - `REDLINE` → 另加载 `references/negotiation-fallbacks.md` + `references/tier-selection.md` + 作为基准的相关模板；如相对方草稿基于 2021/915，另加载 2021/915 参考文本。
   - `JOINT_CONTROLLER` → 切换到 `references/art26-joint-controller.md` 和 `templates/jca-{lang}.md`。Art. 28 检查清单不再作为首要视角。
3. **条件性**——凡国际传输在范围内，或源 DPA 提及 SCC / Drittlandübermittlung / Standardvertragsklauseln 时，加载 `references/sccs-module-guide.md`。注意：2021/915（第 28 条）与 2021/914（第五章）是不同文件——`sccs-module-guide.md` 覆盖 2021/914，`2021-915-commission-text-{en,de}.md` 覆盖 2021/915。

## 各模式输出结构

### REVIEW_QUICK 输出

1. **执行摘要**（3–5 句）：整体合规状况与头条问题。
2. **Art. 28(3)(a)–(h) 覆盖表**：每项义务标记 `通过` / `薄弱` / `缺口` / `缺陷`，附一行理由。
3. **序言与框架**（处理事项、期限、性质、目的、数据类型、数据主体类别、控制人的权利与义务）——有还是缺失？
4. **SCC 充分性**（如传输在范围内）：模块正确吗？附件填写了吗？是否引用 TIA？
5. **需要修复的前 3 大问题**。
6. **建议**：签署 / 附随函签署 / 不修改则不签署 / 升级为 `REVIEW_NEG`。

### REVIEW_NEG 输出

1. 执行摘要 + 立场建议。
2. 角色确认 + 场景摘要（作为后续分析的锁定基础）。
3. **逐条对照表**：条款编号 | 范围内的义务 | 现行文本大意 | 问题 | 风险等级（1 = 阻碍签署 / 2 = 实质性 / 3 = 润色）| 拟议修改。
4. **附件审查**：
   - 附件 1（处理描述）——细节是否足以满足 Art. 28(3) 序言部分？
   - 附件 2（TOMs）——是否具体、可衡量、对应 Art. 32(1)(a)–(d)？
   - 附件 3（子处理人）——是否列明现有子处理人并界定通知/异议机制？
   - 附件 4（传输 + SCC）——模块、附件 I–III、TIA？
5. **谈判策略**：必须获得 / 应当获得 / 锦上添花，并按实际谈判顺序排列。
6. **退出条件**——即使尽力谈判，用户也不应签署的条款情形。

### DRAFT 输出

1. 以所请求语言的完整 DPA / AVV 正文。
2. 附件 1——根据信息接收内容填写。
3. 附件 2——模板骨架，或如已提供 TOMs 则填写完整。
4. 附件 3——填写完整，或“签署时无”并附通知机制。
5. 附件 4——仅当传输在范围内；并入正确的 SCC 模块。
6. **起草说明**（独立章节）：留作备选的条款、所做的场景假设、需要用户跟进的事项。

### REDLINE 输出

1. **标注版**：新增内容用**粗体**，删除内容用~~删除线~~。必须复现相对方的条款编号以保证可追溯性。
2. **封面备忘录**：变更摘要；按条款说明理由；备用立场（T1 / T2 / T3）；每项变更预期会遇到的相对方异议。
3. 如需处理不值得重开主 DPA 谈判的剩余缺口，附**随函（side letter）草稿**。

### JOINT_CONTROLLER 输出

1. **角色分析**——为何这是 JC 而非处理人关系；引用 EDPB 07/2020 作为锚点。
2. 以所请求语言的 **JCA 正文**。
3. **分配矩阵**：谁负责什么（数据主体权利、向监管机构报告数据泄露、向数据主体通知泄露、安全、DPIA、传输、投诉、审计）。
4. 依第 26(2) 条的**公开摘要**——简短、通俗语言、供数据主体查阅（通常通过隐私声明）。
5. 载明无论分配如何，数据主体均有权向任一方行使权利的序言。

## 质量门禁——交付前核实

- [ ] 角色已确认，Art. 28 与 Art. 26 筛查通过。
- [ ] Art. 28(3) 序言部分所有要素均已处理（处理事项、期限、性质、目的、数据类型、数据主体类别、控制人的权利与义务）。
- [ ] 八项 (a)–(h) 义务全部覆盖。
- [ ] 子处理人机制已界定（一般或特定同意 + 通知 + 异议权）。
- [ ] 审计权已明确（频率、范围、费用分担、第三方审计员选项、保密性）。
- [ ] 删除/返还选择机制已界定（Art. 28(3)(g)），并为法定义务保留留存例外。
- [ ] 如涉及传输：SCC 模块已识别，附件 I.A/I.B/I.C/II/III 在范围内，TIA 已引用。
- [ ] 如涉及特殊类别 / 第 10 条数据：已标记强化版 TOMs。
- [ ] 责任分配反映用户的立场（而非泛泛的样板条款）。
- [ ] 全文语言一致（除非采用双语并列格式，不得出现混合语言条款）。
- [ ] 对客户交付物附执业备注——用户下一步应做什么。

## 风格与语气

- **德文输出**：正式法律语体；不使用“Sie”称呼（法人实体称为“der Verantwortliche”/“der Auftragsverarbeiter”）；标准术语是 **Auftragsverarbeitungsvertrag** 或 **AV-Vertrag**，而非“DPA”。
- **英文输出**：标准商业合同语体；定义术语首次出现时用**粗体**；义务用主动语态（“The Processor shall ...”）。
- **不使用营销语言。不使用破折号（em dashes）。** 处理人义务用主动语态；仅标准合同惯用语要求时使用被动语态。
- **对 OneZero Legal 的客户交付物**：每份输出结尾附一段**执业备注（Practitioner's note）**——用户实际下一步应做什么（签署 / 提出异议 / 索取信息 / 升级）。

## 范围外（不得静默扩展至这些领域）

- 超出附件 2 骨架的独立 TOMs 起草（应使用 Art. 32 专项指引）。
- 完整 TIA（传输影响评估）文件——标记要求并引用 TIA 技能（如可用）。
- DPIA 文件——引用 DPIA Navigator 技能。
- 处理活动记录（Verzeichnis von Verarbeitungstätigkeiten）——独立任务。
- 实质性数据主体权利工作流——引用专用技能（如可用）。

如用户要求上述任何内容，应明示本技能的边界止于 DPA，并提供切换方案。

## 相关 GDPR 技能

本技能可独立使用，也与我其他欧盟数据保护技能配套良好——可单独安装任一项，或组合使用：

- **DPIA Sentinel**——第 35 条数据保护影响评估
- **GDPR Breach Sentinel**——第 33/34 条泄露响应与通知
- **Privacy Notice Generator**——第 13/14 条隐私声明
- **Transfer Impact Assessment (TIA)**——第五章传输评估
- **Legitimate Interest**——第 6(1)(f) 条合法性利益评估/利益衡量测试