Dpa Art 28 Oliver Schmidt Prietz

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

目的

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

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

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

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

如不明确，请询问。 不要在 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) 条合法性利益评估/利益衡量测试