gdpr-audit

GDPR 审计

一项由检测指南驱动的审计技能。读取代码／计划／架构／IaC 工件，并返回结构化的发现报告，其中包含 GDPR 条款引用、严重程度、置信度、证据和建议的修复措施。

输出是“对所提供材料进行技术性 GDPR 审计”——绝不能称为“符合 GDPR”或“不符合 GDPR”。 合规性属于法律认定；此技能提供技术证据和差距分析。始终在报告末尾附上免责声明。

适用场景

• 审计现有代码库、仓库或目录树
• 审查实现计划、设计文档或 RFC，评估其对 GDPR 的影响
• 审查数据库架构或数据模型中的个人数据处理方式
• 审查 IaC（Terraform / Pulumi / CDK / k8s 清单）中的数据传输、加密和区域限制
• DPIA 前期技术范围界定
• 供应商接入（审计新处理方／SDK 的集成代码）

不适用场景

• 从头起草隐私声明、DPA 或 DPIA——这是写作任务，而非审计
• 合规认证、监管申报或与 DPA 往来——需要具备资质的 DPO／律师
• 组织成熟度评估（培训、治理、DPO 独立性）——无法从代码／计划输入中判断
• 审计非 GDPR 司法管辖区（CCPA、LGPD、PIPL）——引用条款和触发条件会有误

---

审计工作流

按顺序执行以下阶段。不要跳过任何阶段。

阶段 1 — 范围声明

在列出任何发现之前，明确说明审查了哪些内容，以及未审查哪些内容。

## Scope
- Materials reviewed: <repo, commit/SHA, branch, paths or "full tree">
- Date of audit: <YYYY-MM-DD>
- Excluded: <e.g., binary assets, vendored deps, test fixtures, .git history>
- Assumptions: <e.g., "controller role assumed unless evidence indicates processor role">
- Missing context: <list of org/policy artifacts not provided to the audit>

这可以防止审计被误解为穷尽性审计。

阶段 2 — 处理映射（先构建，再据此查找）

扫描问题之前，先构建处理映射。之后的每项发现都要对应到其中一行。

| Activity | Data categories | Subjects | Purpose | Lawful basis (claimed / inferred / unclear) | Recipients / processors | Country / region | Retention (claimed / inferred / unclear) |

映射信息来源：API 路由、数据库架构、环境变量、IaC 区域限制、第三方 SDK 调用（Stripe、Auth0、Segment、GA、Sentry、Datadog、Supabase、AWS 客户端）、后台作业、cron、队列消费者、ML / AI 训练流水线。

如果无法构建处理映射（工件确实不透明），请说明原因并停止。没有处理映射的发现报告缺乏依据。检测信号请参阅 references/01-data-discovery.md。

阶段 3 — 使用参考指南进行检测扫描

针对处理映射中的每一行，逐一查阅 references/ 中的相关指南。每份指南都是检测指南，包含：检查内容、信号、严重程度规则、误报控制、特定技术栈示例和所需证据。

每次审计都要查阅以下指南：01、02、06、07、09、10、14、15。 条件适用的指南（参见下文的触发条件叠加规则）：03、04、05、08、11、12、13。

阶段 4 — 输出发现

使用下方的架构输出发现。每个独立差距对应一项发现。

阶段 5 — 组装报告

顺序：范围 → 处理映射 → 发现表（每种发现类型内按严重程度从 Critical 到 Low 排序）→ 发现详情 → 按发现类型分布的摘要 → 建议的后续操作 → 免责声明。

阶段 6 — 提供深入排查选项

报告之后，提供以下内容：

“我可以根据要求为其中任意发现起草具体补丁。告诉我发现编号，我会生成实际的代码／SQL／IaC／Markdown 更改。”

不要在初始报告中生成补丁——它们会掩盖审计的重点。

---

发现架构

每项发现都必须包含以下字段。缺少任何字段都表示该发现不完整。

id: F-NN                       # sequential within report
title: <short noun phrase>
severity: Critical | High | Medium | Low
finding_type: confirmed_issue | likely_issue | evidence_gap | advisory
confidence: High | Medium | Low
risk_to_rights: <what could happen to a data subject — not "fines">
location: <file:line | section heading | "(absence)">
articles: [Art. 5(1)(c), Art. 25(2), Recital 39]
guidance: [EDPB Guidelines 4/2019 on Article 25, ICO Right of Access guidance]   # optional
affected_data: [email, IP, payment, health, children, employees, ...]
affected_subjects: [end users, employees, vendor staff, ...]
processing_activity: <signup | billing | analytics | recommendation | support_export | ...>
evidence: |
  <verbatim snippet from code / plan, with file:line>
recommended_fix: |
  <1–3 sentences. Not a patch.>
verification_needed: |
  <what specific evidence would close this finding>

严重程度分级

严重程度	含义
严重	明确违规，且对权利构成高风险，证据置信度高。示例：在公开日志中明文记录个人身份信息（PII）；欧盟消费者数据被发送至第三国，且没有传输机制；未经数据保护影响评估（DPIA）的高风险画像分析。
高	明确违规，或存在高风险缺口且证据置信度较高。若监管机构发现，可能会采取行动。
中	存在重大缺口，可通过调整设计予以纠正。在实际审计中会要求整改。
低	未遵循最佳实践。没有即时风险。

严重程度不等于可能性 × 影响——这种伪精确会造成误导。严重程度体现的是审计判断；置信度是另一个独立维度。

finding_type

类型	含义	示例
confirmed_issue	有确凿证据表明存在违规	analytics.track(user.email) 在记录同意之前触发
likely_issue	有强烈信号，但缺少上下文，无法确定	存在高风险画像分析代码；合法依据声明不明确
evidence_gap	应当能看到某项控制措施，但未发现	检测到 Stripe SDK；在提供的材料中未找到 DPA 证据
advisory	技术上站得住脚的设计层面改进建议	在 analytics_events 中，可用假名化取代直接标识符

evidence_gap 的判定原则： 仅当有正面证据表明存在数据处理，且有理由预期应当存在某项控制措施时，才标记为缺口。"没有 docs/ropa.md" 不是一项发现。"Stripe SDK + 跨境数据流 + 提供的材料中没有 DPA 文件" 是一项 evidence_gap。此技能不会凭空臆造缺乏依据的组织政策缺口。

置信度

级别	含义
高	有直接代码证据，不存在合理的其他解释
中	根据信号作出强推断；存在其他解释，但可能性较低
低	基于模式的疑点；需要人工核实

---

触发条件叠加规则

在触发条件成立时应用这些规则。它们会提高严重程度、强制审查相关章节，并补充国家层面的背景信息。

儿童数据叠加规则

触发条件： 架构或表单接受出生日期、年龄、学校、家长联系方式；产品面向消费者、社交或教育领域；注册表单没有年龄门槛。 影响： 所有涉及儿童数据的发现，严重程度提高一级。引用第 8 条和序言第 38 段。标记以供核实成员国的年龄门槛（13–16 岁）。对数据最小化原则进行更严格的审查。

特殊类别数据叠加规则（第 9、10 条）

触发条件： 架构字段显示涉及健康、生物识别、遗传、种族／族裔、政治、宗教、工会、性生活、性取向、刑事定罪等数据；或涉及医疗、人力资源、保险领域。 影响： 对任何未受保护的数据处理，严重程度至少为高。必须明确引用第 9(2) 条的依据。提高安全要求（结合第 32 条和第 9 条）。几乎肯定需要 DPIA（强制审查 ch14）。

画像分析／自动化决策叠加规则（第 22 条）

触发条件： 代码对个人数据进行评分、排名、欺诈检测、推荐、嵌入计算、自动 KYC 或自动化就业决策。 影响： 强制审查 ch13 和 ch14。即使系统并非“完全自动化”，但在实际中是按这种方式使用，也要标记第 22 条（根据 EDPB 指南，人类仅对模型输出盖章认可，也算作完全自动化）。

跨境／供应商叠加规则

触发条件： SDK 或 HTTP 客户端指向非欧盟端点；AWS 区域不在 eu-* 范围内；GCP 区域不在 europe-* 范围内；外部 SaaS 未明确说明数据存储在欧盟。 影响： 强制审查 ch11 和 ch12。

国家背景补充

**触发条件：**用户提及某个成员国、仓库包含 DE/FR/IT/ES/NL 本地化内容，涉及就业场景，或涉及医疗保健／保险／金融领域。 按司法管辖区添加说明：

• **德国（BDSG）：**从事自动化 PII 处理的员工人数 ≥ 20 时，必须指定 DPO（§ 38）；§ 26 就业数据；§ 4 视频监控；§ 31 信用评分；员工委员会对监控工具享有共同决定权。
• **法国（LIL/CNIL）：**Cookie 指引更严格；员工监控需要符合 CNIL 要求的影响评估。
• **英国（UK GDPR + DPA 2018）：**ICO 指引；国际传输使用 UK IDTA 或 EU SCCs 附录。
• **意大利（Garante）：**已就 AI／训练数据来源发布意见；Cookie 执法。
• **其他成员国：**标记为待核实——各国的例外规定不尽相同。

---

DPIA 路由规则（无论由哪一章节触发，均为强制要求）

报告发布前，检查处理活动是否达到任何 DPIA 门槛。如果 EDPB 的 9 项标准中有两项或以上适用，即使审计其余部分未发现问题，也要针对 ch14 输出一项发现：

1. 评估或评分（包括画像分析和预测）
2. 产生法律影响／重大影响的自动化决策
3. 系统性监控（包括公众可进入的区域）
4. 敏感数据或高度个人化的数据
5. 大规模处理数据
6. 匹配或合并数据集
7. 涉及弱势群体的数据（儿童、员工、患者）
8. 创新用途或新技术／组织解决方案（AI、IoT、生物识别）
9. 阻止数据主体行使权利或使用服务／合同的处理活动

EDPB 于 2026 年 4 月通过了一份供咨询使用的 DPIA 模板——请引用该模板，而非旧版 WP29 模板。

---

输出格式

# GDPR Audit Report

## Scope
<Phase 1 block>

## Processing map
<Phase 2 table>

## Findings — confirmed issues (Critical → Low)
| ID | Sev | Conf | Article(s) | Activity | Title |

## Findings — likely issues
| ID | Sev | Conf | Article(s) | Activity | Title |

## Findings — evidence gaps
| ID | Sev | Conf | Article(s) | Activity | Title |

## Findings — advisory
| ID | Sev | Conf | Article(s) | Activity | Title |

## Finding details
F-01
  Severity: Critical / Confidence: High / Type: confirmed_issue
  Articles: Art. 5(1)(f), Art. 32(1)
  Risk to rights: <...>
  Location: src/auth/login.py:42
  Affected data: email, IP address
  Affected subjects: end users
  Processing activity: signup
  Evidence:
    logger.info(f"login attempt: {email} from {request.client_host}")
  Recommended fix:
    Hash the user identifier in log output; mask IP to /24 for security analytics if needed; configure structured-logging redaction.
  Verification needed:
    Show the redaction config and a sample log line after change.

F-02 ...

## Summary
- Confirmed issues: <N>
- Likely issues: <N>
- Evidence gaps: <N>
- Advisory: <N>
- DPIA recommended: yes/no — <reason>

## Recommended next actions
1. <ranked list, highest-leverage first>

## Disclaimer
This is a technical GDPR audit of the provided materials. It is not legal advice and does not constitute a compliance determination. Consult a qualified DPO or data protection lawyer for legal questions, supervisory authority engagement, or material decisions.

---

参考指南索引

检测指南位于 references/，编号为 01–15（在上述补充内容中以 ch01–ch15 表示）。

参考编号	标题	主要条款	适用情形
01	数据发现、分类与处理映射	Art. 4, 30	始终适用（用于指导第 2 阶段）
02	目的限制、合法依据、特殊类别数据处理依据	Art. 5(1)(b), 6, 9, 10	始终适用
03	透明度与告知	Art. 12–14	存在面向用户的数据收集点时
04	同意与偏好管理	Art. 6(1)(a), 7, 8	任何活动声称／要求取得同意时
05	Cookie、跟踪、分析、SDK	Art. 6, ePrivacy 5(3)	检测到浏览器端跟踪／分析／营销时
06	设计隐私／默认隐私 + 数据最小化	Art. 5(1)(c), 25	始终适用
07	保留、删除、备份、派生数据	Art. 5(1)(e), 17	始终适用
08	DSAR 与数据主体权利工作流	Art. 12, 15–22	产品持有可识别数据主体的个人数据时
09	安全、访问控制、加密、韧性	Art. 32	始终适用
10	日志记录、遥测、审计跟踪、过量收集	Art. 5(1)(c), 5(2), 32	始终适用
11	供应商、处理者、子处理者、控制者／处理者角色	Art. 24, 26, 28, 29	检测到第三方处理者时
12	国际传输与 TIA	Art. 44–49, Schrems II	检测到非 EU 数据流时
13	画像分析、自动化决策、AI、模型训练	Art. 22, Recital 71	触发画像分析／AI 补充规则时
14	DPIA／高风险分流 + 事先咨询	Art. 35, 36	始终适用（DPIA 路由规则）
15	问责证据：RoPA、LIA、DPA、SCC/TIA、违规登记册、违规通知	Art. 5(2), 30, 33, 34	始终适用

---

需要抵制的常见托词

借口	事实
“这里没有个人身份信息，只是电子邮件。”	电子邮件属于个人数据（第 4(1) 条）。
“我们依据合法利益处理，因此不需要征得同意。”	合法利益要求记录并存档 LIA。直接营销仍会触发第 21 条规定的反对权。
“这只是分析，数据是匿名的。”	带有稳定标识符（Cookie、指纹、user_id）的个人级事件属于假名化数据，而非匿名数据。仍然是个人数据。
“我们是处理者，不是控制者。”	处理者依据第 28(3)、32、33(2) 条也负有直接义务。
“Stripe 会处理支付合规事宜。”	Stripe 的合规情况仅涵盖 Stripe 的处理活动。集成系统本身也负有控制者义务。
“我们不需要做 DPIA，我们没做什么特别的事。”	DPIA 门槛 = 第 35(3) 条 + EDPB 的 9 项标准。许多“普通”的 SaaS 都符合 2 项或更多标准（分析 + 员工 + 供应商 + 评分）。
“我们的云服务商符合 GDPR。”	服务商合规 ≠ 你合规。你仍需签订 DPA、确定传输机制并选择区域。
“用户已同意 ToS。”	同意 ToS 不等于第 7 条规定的同意。捆绑同意无效。
“我们会按请求删除数据，这就够了。”	删除权（第 17 条）是七项权利之一。访问、更正、可携带、限制处理、反对以及自动化决策相关权利都需要相应的工作流。
“我们不需要 DPA——他们是我们数据次级处理者的次级处理者。”	第 28(2) 和 28(4) 条规定了次级处理者链条的义务。每个环节都需要通过合同传递义务。