conducting-gdpr-dpia について
プライバシー、法務、セキュリティ担当者向けのGDPRデータ保護影響評価(DPIA)ガイドです。第35条とEDPBの指針に沿って、スクリーニング、リスク評価、軽減、DPOレビュー、継続的な見直しを扱います。
主な機能
- 01DPIAが必要となる条件の特定
- 02処理活動とデータライフサイクルの整理
- 03必要性・比例性・リスクの評価
- 04技術的・組織的な対策の計画
- 05DPOの助言記録とレビュー日程の設定
活用シーン
- 01新たな処理にDPIAが必要か判断
- 02高リスクのデータ処理活動を評価
- 03DPIAの完全性確認と更新計画
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ mukul975/ privacy-data-protection-skills --skill conducting-gdpr-dpiaインストール後、Claude Code で/conducting-gdpr-dpiaを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
assets/template.mdreferences/standards.mdworkflows.mdscripts/process.py詳細
GDPR データ保護影響評価の実施
概要
データ保護影響評価(DPIA)は、データ処理活動によって自然人の権利および自由に生じるリスクを特定、評価、軽減するため、GDPR 第35条で義務付けられている体系的なプロセスです。DPIA は単なるコンプライアンス上のチェック項目ではなく、処理の開始前に実施し、処理ライフサイクル全体を通じて更新する必要がある、継続的なリスク管理手段です。このスキルは、欧州データ保護会議が WP248rev.01(データ保護影響評価に関するガイドライン)で推奨する方法論を実践し、Art. 35(1)-(11) の強制力のある要件を取り入れています。
DPIA が必須となるトリガー — Art. 35(3)
データ処理によって自然人の権利および自由に高いリスクが生じる可能性がある場合、特に以下のケースでは DPIA が必要です。
Art. 35(3) に基づく自動的なトリガー
| トリガー | GDPR の参照先 | 説明 |
|---|---|---|
| 重大な影響を伴う、体系的かつ広範なプロファイリング | Art. 35(3)(a) | データ主体に法的効果または同様に重大な影響をもたらす、プロファイリングを含む自動処理 |
| 大規模な特別カテゴリデータまたは犯罪データ | Art. 35(3)(b) | Art. 9(1) に基づくデータ(健康、生体認証、遺伝、人種、政治、宗教、性的指向、労働組合)または Art. 10(有罪判決に関するデータ)の大規模な処理 |
| 公共の場所の体系的な大規模監視 | Art. 35(3)(c) | CCTV による監視、ドローンによる監視、Wi-Fi トラッキング、または一般にアクセス可能な区域のその他の体系的な大規模監視 |
EDPB WP248rev.01 の基準 — 2つ以上のトリガーに該当する場合は DPIA が必要
EDPB は、高リスクのデータ処理を特定するための9つの基準を定めています。データ処理活動がこれらの基準のうち2つ以上に該当する場合、原則として DPIA が必要です。
- 評価またはスコアリング — プロファイリング、予測、信用スコアリング、行動分析
- 法的効果または重大な影響を伴う自動意思決定 — サービス、契約、または給付へのアクセスを決定する処理
- 体系的な監視 — データ主体の観察、追跡、または監視
- 機微データまたは高度に個人的な性質を持つデータ — Art. 9 の特別カテゴリ、金融データ、通信メタデータ、位置データ
- 大規模に処理されるデータ — データ主体の人数、データ項目の量、地理的範囲、処理期間
- データセットの照合または結合 — データ主体の合理的な予想を超えて、複数の情報源からのデータを統合すること
- 脆弱なデータ主体に関するデータ — 子ども、従業員、精神疾患のある人、亡命希望者、高齢者、患者
- 革新的な利用または新しい技術的ソリューションの適用 — アクセス制御と組み合わせた指紋・顔認識、IoT アプリケーション、AI 主導の処理
- データ主体が権利を行使したりサービスを利用したりすることを妨げる処理 — アクセスを遮断する審査プロセスなど。これらに限定されません
DPIA の内容要件 — Art. 35(7)
すべての DPIA には、最低限、以下の4つの要素を含める必要があります。
(a) 処理活動および目的の体系的な説明
- 処理の性質:収集、記録、整理、構造化、保存、適応、変更、検索、閲覧、利用、開示、頒布、結合、制限、消去、破棄
- 範囲:データ主体のカテゴリ、個人データのカテゴリ、量と頻度、地理的範囲
- コンテキスト:管理者とデータ主体の関係、データの取得方法、データ主体の予想
- 目的:Art. 5(1)(b) に基づく具体的な目的、Art. 6(1) に基づく適法な根拠、および該当する場合は Art. 9(2) の条件
(b) 必要性および比例性の評価
- 具体性を伴う適法な根拠の正当化
- 目的制限の分析:各データ項目は、明示された目的に必要ですか?
- データ最小化の評価:データを減らすか、匿名化したデータを使用して目的を達成できますか?
- 保存期間の制限:保存期間は正当化され、遵守されていますか?
- データ主体の権利行使の支援:第15条から第22条の権利をどのように行使できるようにしていますか?
- 該当する場合、第V章に基づく国際移転のための保護措置
(c) 権利および自由に対するリスクの評価
特定した各リスクについて、以下を評価します。
| リスクの側面 | 評価基準 |
|---|---|
| 発生可能性 | まれ(< 10%)、可能性あり(10-50%)、可能性が高い(50-90%)、ほぼ確実(> 90%) |
| 深刻度 | 無視できる(不便)、限定的(重大だが回復可能)、重大(深刻な困難)、最大(不可逆的な結果) |
| リスクレベル | 発生可能性 x 深刻度のマトリックスにより、低、中、高、非常に高のいずれかを算出 |
評価する危害の種類:
- 身体的危害(暴力につながる差別、医療の拒否)
- 物質的危害(金銭的損失、個人情報の盗難、失業)
- 非物質的危害(評判の毀損、精神的苦痛、自律性の喪失)
- 社会的危害(言論の自由に対する萎縮効果、差別、排除)
- 個人データに対する管理の喪失(権利を行使できないこと、処理内容が不明であること)
(d) リスクに対処するための措置
- 技術的措置:保存時および転送時の暗号化(AES-256、TLS 1.3)、第4条(5)に基づく仮名化、アクセス制御(RBAC)、自動削除、監査ログ
- 組織的措置:プライバシーポリシー、スタッフ研修、DPO による監督、インシデント対応手順、第28条に基づくデータ処理契約
- 契約上の措置:データ主体への通知、同意の仕組み、処理者の義務
- 残存リスクの評価:リスク軽減措置の実施後のリスクレベル
DPIA プロセスの方法論
ステップ1:スクリーニングと範囲の設定(第1週)
- Privacy Threshold Analysis の質問票に記入し、DPIA の実施義務を確認します。
- 処理業務の範囲を定義します。対象となるシステム、データフロー、組織単位を特定します。
- DPIA チームを特定します。処理責任者、DPO、IT セキュリティ担当者、法務顧問、および適切な場合は第35条(9)に基づくデータ主体の代表者を含めます。
- 既存の文書を収集します。システムアーキテクチャ図、データフローマップ、プライバシー通知、同意書、処理者との契約を含めます。
ステップ2:体系的な説明(第2週)
- 収集から削除までの完全なデータライフサイクルをマッピングします。
- 処理するすべてのデータ項目と、それぞれの適法な根拠を文書化します。
- すべての受領者および再処理者を特定します。
- 国際移転と適用される保護措置の仕組みを文書化します。
- 関連するテクノロジースタックとインフラストラクチャを記録します。
ステップ3:必要性および比例性の評価(第3週)
- 各データ項目について、明示された目的に必要な理由を文書化します。
- より侵襲性の低い代替手段で同じ目的を達成できるか評価します。
- データ最小化の遵守状況を評価します。
- 保存期間が比例的であり、技術的に適用されていることを確認します。
- データ主体が権利を効果的に行使できることを確認します。
ステップ4:リスクの特定と評価(第3~4週)
- データフローマップに基づいて脅威モデリングを実施します(リスクの発生源:内部関係者、外部の攻撃者、処理者、システム障害)。
- 各脅威について、第35条(7)(c)のマトリックスを使用して発生可能性と深刻度を評価します。
- 一意の識別子を付けて、リスク台帳にリスクを記録します。
- 軽減措置を講じる前の固有リスクレベルを算出します。
ステップ 5:リスク軽減策(第 4~5 週)
- 高リスクまたは非常に高いリスクごとに、具体的な技術的および組織的な対策を特定します。
- 各対策によって期待されるリスク軽減効果を文書化します。
- リスク軽減後の残存リスクレベルを算出します。
- 残存リスクが高リスクまたは非常に高いリスクのままである場合は、第 36 条に基づき監督機関への事前協議に進みます。
ステップ 6:DPO の助言と承認(第 5~6 週)
- 第 35 条第 2 項に基づく独立した審査のため、完了した DPIA を DPO に提出します。
- DPO の助言と、それに従ったかどうかを文書化します。従わなかった場合は、その理由も文書化します。
- 処理責任者の承認と上級管理職の承認を取得します。
- DPIA を中央 DPIA 登録簿に記録し、予定された見直し日を設定します。
ステップ 7:継続的な見直し
- リスクに重大な変更が生じた場合(新たなデータカテゴリー、新たな受領者、技術の変更、セキュリティインシデント、規制の変更など)、DPIA を見直します。
- 少なくとも年 1 回、定期的な見直しを実施します。
- すべての見直し結果を文書化し、DPIA のバージョンを管理します。
DPO への相談 — 第 35 条第 2 項
管理者は、データ保護責任者が任命されている場合、その助言を求めなければなりません。DPO はスクリーニング段階から関与する必要があります。第 39 条第 1 項(c)に基づき、DPO は DPIA に関する助言を行い、その実施状況を監視する役割を担います。管理者は、DPO の助言と、助言に従わなかった場合の理由を文書化しなければなりません。
データ主体の意見 — 第 35 条第 9 項
適切な場合、管理者は予定している処理について、データ主体またはその代表者の意見を求めなければなりません。方法としては、以下が考えられます。
- データ主体の代表的なサンプルを対象とするアンケートまたはフォーカスグループ
- 従業員が影響を受ける場合の労働組合との協議
- 大規模な政府による処理に関する公開協議
- 健康データの処理に関する患者支援団体との協議
管理者は、データ主体の意見を求めたかどうか、求めなかった場合はその理由を文書化しなければなりません。
監督機関のリスト — 第 35 条第 4~5 項
各監督機関は、DPIA が必要な処理業務のリスト(第 35 条第 4 項)を公表します。また、DPIA が不要な処理業務のリストを公表する場合もあります(第 35 条第 5 項)。管理者は、該当する国のリストを確認しなければなりません。主な例:
- CNIL(フランス):従業員のスコアリング、健康データのウェアハウス、生体認証によるアクセス制御など、DPIA が必要な 14 種類の処理
- ICO(英国):目に見えない処理、オンラインでの個人の追跡、自動意思決定など、DPIA が必要な 10 種類の処理
- BfDI(ドイツ):識別を目的とした遺伝データまたは生体データの処理、信用調査機関によるスコアリング、大規模なプロファイリング
DPIA でよく見られる不備
- 一般的すぎるリスクの記述:「データ侵害」とだけ記載し、攻撃経路、影響を受けるデータカテゴリー、具体的な被害を明示していない
- 比例性の分析がない:処理が必要かつ比例しているかを評価せず、説明からリスクの特定に進んでいる
- 残存リスクの算出がない:対策を特定しているものの、リスクが許容可能なレベルまで軽減されるか評価していない
- DPO の助言が文書化されていない:実質的な助言を記録せず、署名だけで DPO の関与を済ませている
- DPIA が更新されない:評価を一度実施した後、処理に重大な変更があっても見直していない
- 第 35 条第 9 項に関する根拠がない:データ主体の意見を求めたかどうか、求めなかった理由を文書化していない
執行に関する先例
- カロリンスカ研究所(スウェーデンのデータ保護当局、2019年):第35条で義務付けられているDPIAを実施せずに遺伝データを処理したとして、20万スウェーデンクローナの罰金が科されました。
- オーストリア郵便(オーストリアのデータ保護当局、2019年):政党への支持傾向のプロファイリングに関連して1,800万ユーロの罰金が科されました。DPIAの不備も要因の一つでした。
- Clearview AI(CNIL、2022年):DPIAを実施せず、適法な根拠もないまま生体データを処理したとして、2,000万ユーロの罰金が科されました。
- Real Madrid CF(AEPD、2023年):第35条第3項(c)に基づく大規模な公共エリアの監視に関するDPIAを実施せず、スタジアム内にWi-Fiトラッキングを導入したとして制裁を受けました。
統合ポイント
- 第36条 事前協議:リスク軽減後も残存リスクが高い場合、管理者は処理を開始する前に監督機関に相談する必要があります。
- 第30条 処理記録:一貫性を確保するため、DPIAの調査結果をRoPAと相互参照する必要があります。
- 第25条 データ保護の設計段階からの組み込み:DPIAで特定されたリスク軽減策は、プライバシー・バイ・デザインの実装に直接反映されます。
- 第33~34条 データ侵害の通知:DPIAのリスク評価は、データ侵害の重大度分析と通知の判断に役立ちます。