关于 gdpr-ropa-audit
gdpr-ropa-audit 是面向数据保护与合规团队的 GDPR 第 30 条处理活动记录（RoPA）审计技能。它提供分阶段方法，检查记录的完整性、准确性、时效性并制定整改措施。
主要功能
- 01核对控制者与处理者记录字段
- 02检查业务活动清单是否完整
- 03验证记录准确性与时效性
- 04按严重程度整理审计发现
- 05安排整改责任人与复查
适用场景
- 01为监管机构审查准备 RoPA
- 02发现遗漏或过时的处理活动记录
- 03核验数据流、接收方和国际传输
- 04跟进审计问题的整改
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/gdpr-ropa-audit确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
assets/template.mdreferences/standards.mdworkflows.mdscripts/process.py详细介绍
开展 GDPR 第 30 条记录审计
概述
GDPR 第 30 条要求每位控制者和处理者以书面形式维护其负责的处理活动记录。本技能提供一套结构化方法，用于依据第 30 条第 1 款（控制者）和第 30 条第 2 款（处理者）规定的详尽字段要求审计 RoPA 条目，确保记录完整、准确，并做好接受监管机构审查的准备。
控制者记录要求 — 第 30 条第 1 款
控制者维护的每项处理活动记录都必须包含：
| 字段 | GDPR 参考条款 | 描述 |
|---|---|---|
| 控制者身份和联系方式 | 第 30 条第 1 款 (a) | 控制者、共同控制者和 DPO 的名称、地址和联系方式 |
| 处理目的 | 第 30 条第 1 款 (b) | 每项处理活动具体、明确且合法的目的 |
| 数据主体类别 | 第 30 条第 1 款 (c) | 识别所有数据主体群体（员工、客户、患者、未成年人） |
| 个人数据类别 | 第 30 条第 1 款 (c) | 每项活动所处理的个人数据类型（标识符、财务、健康、生物识别） |
| 接收方类别 | 第 30 条第 1 款 (d) | 所有接收方，包括处理者、共同控制者和第三国接收方 |
| 国际传输 | 第 30 条第 1 款 (e) | 向第三国或国际组织传输数据，并附上保障措施文档 |
| 保留期限 | 第 30 条第 1 款 (f) | 预计删除不同类别数据的时限 |
| 技术和组织措施 | 第 30 条第 1 款 (g) | 对保护数据的第 32 条安全措施作一般性说明 |
处理者记录要求 — 第 30 条第 2 款
| 字段 | GDPR 参考条款 | 描述 |
|---|---|---|
| 处理者身份和联系方式 | 第 30 条第 2 款 (a) | 处理者、处理者代表其行事的每位控制者，以及 DPO 的名称和联系方式 |
| 处理类别 | 第 30 条第 2 款 (b) | 代表每位控制者开展的处理类别 |
| 国际传输 | 第 30 条第 2 款 (c) | 向第三国或国际组织传输数据，并附上保障措施文档 |
| 技术和组织措施 | 第 30 条第 2 款 (d) | 对第 32 条安全措施作一般性说明 |
审计方法
阶段 1：清单验证
- 从数据保护管理系统或文档库中调取当前 RoPA。
- 将 RoPA 与企业应用清单进行交叉核对，找出尚未记录的处理活动。
- 对照组织架构图，核实各业务部门是否已提交处理活动申报。
- 通过部门访谈，检查是否已记录影子 IT 和非正式数据处理活动（电子表格、共享云盘）。
- 验证记录是否涵盖自动化和手动处理活动。
阶段 2：字段完整性检查
- 对每条控制者记录，核实第 30 条第 1 款 (a) 至 (g) 规定的七项必填字段均已填写具体内容，而非笼统描述。
- 对每条处理者记录，核实第 30 条第 2 款 (a) 至 (d) 规定的四项必填字段均已填写。
- 标记处理目的描述过于宽泛的条目（例如，“业务运营”而非“为履行雇佣合同而计算工资”）。
- 确认保留期限以具体时长或标准表示，而非“在必要期限内”。
- 核实安全措施所指的是实际实施的控制措施，而非计划中的措施。
阶段 3：准确性核验
- 抽查 20% 的 RoPA 条目，并采访处理活动负责人，以核验记录的目的、数据类别和接收方是否准确。
- 将记录的数据流与实际系统架构图和数据流图进行对比。
- 核验国际传输记录是否与网络和应用日志中观察到的实际数据路由相符。
- 确认所列接收方仍具备有效的法律依据和合同安排（针对处理者的第 28 条协议、针对共同控制者的第 26 条安排）。
阶段 4：时效性评估
- 根据组织规定的审核周期，检查每条 RoPA 记录的上次审核日期（建议至少每年审核一次，或在发生重大变更时审核）。
- 找出引用已停用系统、将前员工列为联系人或合同已到期的条目。
- 核实自上次审核周期以来新增的处理活动是否已添加到 RoPA。
- 与变更管理日志和 DPIA 登记册交叉核对，找出未记录的处理变更。
阶段 5：报告与整改
- 编制审计发现报告，并按严重程度对问题进行分类：严重（缺少必填字段）、主要（字段不完整或不准确）、次要（格式或行政管理问题）。
- 为每项发现指定整改负责人和截止日期。
- 对严重问题安排在 30 天内进行后续审核，对主要问题安排在 90 天内进行后续审核。
- 更新 RoPA 治理流程，以解决审计中发现的系统性问题。
豁免考量
第 30(5) 条为员工人数少于 250 人的组织提供有限豁免，但在以下情况下不适用：
- 处理活动可能对数据主体的权利和自由造成风险
- 处理活动并非偶尔进行
- 处理活动包含第 9(1) 条规定的特殊类别数据，或第 10 条规定的与刑事定罪相关的个人数据
实际上，任何定期处理客户或员工数据的组织，大多都不符合该豁免条件。
常见审计发现
- 缺少处理者记录：控制者维护了自己的记录，却未确保处理者维护第 30(2) 条规定的记录。
- 联系人信息过时：组织重组后，DPO 或控制者代表的详细信息已过时。
- 目的描述含糊：目的按部门而非按处理活动描述，无法证明符合第 5(1)(b) 条的目的限制原则。
- 未列明保留计划：保留期限仅记录为“按照政策执行”，未注明实际期限或删除标准。
- 传输文档不完整：记录国际传输时未注明所依赖的保障机制（SCC、充分性决定、BCR 或减损条款）。
- 未描述安全措施：第 30(1)(g) 条字段留空，或仅填写“加密”，未描述现行的组织和技术措施。
集成点
- DPIA 登记册：将标记为高风险的 RoPA 条目与第 35 条 DPIA 登记册交叉核对。
- 泄露日志：核实涉及过往泄露的处理活动是否已在 RoPA 条目中更新安全措施。
- 供应商登记册：验证 RoPA 中列出的所有处理者是否都有对应的第 28 条数据处理协议。
- 培训记录：确认处理活动负责人已完成所需的数据保护培训。
评论
支持 Markdown