gdpr-audit

GDPR 監査

検出ガイドに基づく監査スキルです。コード／計画／スキーマ／IaC の成果物を読み込み、GDPR の条文引用、重大度、確信度、証拠、推奨される修正を含む、構造化された指摘レポートを返します。

出力は「提供された資料の技術的な GDPR 監査」であり、「GDPR に準拠している」または「準拠していない」としてはなりません。 準拠性の判断は法的判断です。このスキルが提供するのは、技術的な証拠とギャップ分析です。レポートの末尾には必ず免責事項を記載してください。

使用する場面

• 既存のコードベース、リポジトリ、またはディレクトリツリーの監査
• GDPR への影響を考慮し、実装計画、設計ドキュメント、または RFC をレビューする場合
• 個人データの取り扱いについて、データベーススキーマまたはデータモデルをレビューする場合
• データ移転、暗号化、リージョン制約について、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 ルート、DB スキーマ、環境変数、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 — 指摘事項の提示

以下のスキーマを使って指摘事項を提示します。個別のギャップごとに指摘事項を 1 件作成します。

フェーズ 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>

重大度の基準

重大度	意味
Critical	権利への高いリスクを伴う直接的な違反であり、確信度も高いものです。例：公開ログに個人識別情報が平文で記録されている、EU の消費者データが移転メカニズムなしで第三国に送信されている、DPIA を実施せずに高リスクのプロファイリングを行っている。
High	直接的な違反、または確信度が相応に高い重大なギャップです。監督機関が発見した場合、措置を講じる可能性が高いものです。
Medium	修正可能な設計上の選択に起因する重大なギャップです。実際の監査では是正が求められるでしょう。
Low	ベストプラクティスからの逸脱です。差し迫ったリスクはありません。

重大度は、可能性 × 影響ではありません。このような疑似的な精密さは誤解を招きます。重大度は監査上の判断を示し、確信度は独立した評価軸です。

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 です。このスキルは、根拠なく組織のポリシー上のギャップを捏造しません。

confidence

レベル	意味
High	コードに直接的な証拠があり、別の解釈がもっともらしく成立しない
Medium	兆候から強く推測されるが、別の解釈も存在する。ただし、その可能性は低い
Low	パターンに基づく疑いがあり、人による確認が必要

---

トリガー別の追加ルール

該当するトリガーが発生した場合は、以下を適用します。重大度を引き上げ、章の確認を必須とし、各国固有の背景情報を追加します。

子どものデータに関する追加ルール

**トリガー：**スキーマやフォームで生年月日、年齢、学校、保護者の連絡先を受け付ける場合、製品が消費者向け／ソーシャル／教育向けである場合、または登録フォームに年齢確認がない場合。 **効果：**子どものデータに関するすべての指摘事項の重大度を1段階引き上げます。第8条と前文38を引用します。加盟国の年齢基準（13～16歳）は要確認として明記します。データ最小化をより厳しく精査します。

特別カテゴリーのデータに関する追加ルール（第9条、第10条）

**トリガー：**スキーマのフィールドが、健康、生体、遺伝、人種／民族、政治、宗教、労働組合、性生活、性的指向、刑事上の有罪判決を示唆する場合、または医療／人事／保険分野である場合。 効果：保護されていない処理の重大度をHigh以上とします。第9条第2項の根拠を明示的に引用する必要があります。セキュリティ要件を引き上げます（第32条と第9条を併せて適用）。DPIA がほぼ確実に必要となるため、第14章の確認を必須とします。

プロファイリング／自動化された意思決定に関する追加ルール（第22条）

**トリガー：**コードが、個人データに基づくスコアリング、ランキング、不正検知、レコメンデーション、埋め込み、自動 KYC、自動化された採用判断を行う場合。 **効果：**第13章と第14章の確認を必須とします。システムが「もっぱら自動化された」ものではなくても、実際の運用でそのように使われている場合は第22条を指摘します（EDPB の指針では、人間がモデルの出力に盲目的に従って承認する場合も、もっぱら自動化されたものとみなされます）。

国境を越えるデータ／ベンダーに関する追加ルール

**トリガー：**SDK または HTTP クライアントが EU 域外のエンドポイントを参照している場合、AWS のリージョンが eu-* の範囲外である場合、GCP のリージョンが europe-* の範囲外である場合、または EU 内でのデータ保管が明らかでない外部 SaaS を利用している場合。 **効果：**第11章と第12章の確認を必須とします。

各国の状況に関する補足

トリガー： ユーザーが特定の加盟国に言及した場合、リポジトリに 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 SCC の補遺を使用します。
• イタリア（Garante）： AI／トレーニングデータの情報源に関する意見が公表されています。Cookie の執行にも注意してください。
• その他の加盟国： 適用除外は国によって異なるため、確認が必要であることを明記してください。

---

DPIA への振り分けルール（どの章がトリガーとなるかにかかわらず必須）

レポートを提出する前に、処理活動が DPIA の基準に該当していないか確認してください。EDPB の 9 つの基準のうち2 つ以上に該当する場合は、監査の他の部分に問題が見つからなくても、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 と表記）。

Ref	タイトル	主な条文	適用する場合
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	常に

---

抵抗すべきよくある言い訳

言い訳	実態
「ここにPIIはありません。メールアドレスだけです。」	メールアドレスは個人データです（Art. 4(1)）。
「正当な利益を根拠にしているので、同意は必要ありません。」	正当な利益には、文書化されたLIAが必要です。ダイレクトマーケティングでは、Art. 21に基づく異議を申し立てる権利も引き続き適用されます。
「これは単なる分析なので、匿名です。」	安定した識別子（cookie、fingerprint、user_id）を伴う個人単位のイベントは、匿名ではなく仮名化されたデータです。依然として個人データです。
「私たちは管理者ではなく、処理者です。」	処理者にもArt. 28(3)、32、33(2)に基づく直接の義務があります。
「支払いコンプライアンスはStripeが対応しています。」	Stripeの対応範囲は、Stripe自身による処理に限られます。連携するシステムには、独自の管理者としての義務があります。
「DPIAは必要ありません。特別なことは何もしていません。」	DPIAの実施基準はArt. 35(3)とEDPBの9つの基準です。多くの「一般的な」SaaSは、2つ以上の基準に該当します（分析＋従業員＋ベンダー＋スコアリング）。
「利用しているクラウドプロバイダーはGDPRに準拠しています。」	プロバイダーの準拠状況と、あなた自身の準拠状況は別です。それでもDPA、移転メカニズム、リージョンの選択が必要です。
「ユーザーはToSにオプトインしました。」	ToSへのオプトインはArt. 7に基づく同意ではありません。抱き合わせの同意は無効です。
「リクエストがあれば削除するので、それで十分です。」	消去（Art. 17）は7つの権利のうちの1つです。アクセス、訂正、データポータビリティ、処理の制限、異議申し立て、自動化された意思決定に関する権利にも、それぞれワークフローが必要です。
「データ処理契約（DPA）は必要ありません。相手は、当社のデータ副処理者のデータ副処理者です。」	Art. 28(2)と28(4)に基づき、副処理者の連鎖に関する義務があります。各段階で、契約上の義務を下流に適用する必要があります。