Article 35 GDPR に基づくデータ保護影響評価（DPIA）は、処理が自然人の権利および自由に対する高いリスクを生じさせるおそれがある場合に必ず必要となります。第29条作業部会（現 EDPB）は9つの基準を定めており、2つ以上が該当する場合は DPIA を実施します。

防御可能な DPIA は5つのステージから成ります。処理の記述、必要性と比例性の評価、リスクの特定、緩和策の特定、そして正式な承認とレビュー予定の設定です。ICO の手法と EDPB ガイドラインは、この構成において緊密に整合しています。

適切に実施された DPIA は、コンプライアンスの儀式ではなく、製品を形づくる成果物です。リスクを早期に表面化させ、データ最小化、保持、アクセスに関する選択を迫ります。最良の DPIA は、最初のコードを書く前に完了しています。

Article 35(1) は、処理が「高いリスクを生じさせるおそれがある」場合に DPIA を求めています。Article 35(3) は3つの必須の場合を挙げています。

1. プロファイリングを含む自動処理に基づく個人的側面の体系的かつ広範な評価であって、法的効果またはこれに類する重大な影響を生じさせるもの。
2. 特別カテゴリーのデータ（Article 9）または犯罪歴データ（Article 10）の大規模な処理。
3. 公衆がアクセス可能な区域の大規模な体系的監視。

ほとんどの監督機関は、常に DPIA を必要とする追加の処理に関する国別リスト（Article 35(4)）を公表しています。主管監督機関のリスト、および加盟国住民を処理する監督機関のリストを確認してください。

判断が不明確な場合は、9基準による判定を行います。2つ以上該当すれば DPIA が必要です。

1. 評価またはスコアリング — プロファイリング、行動分析。
2. 法的効果またはこれに類する重大な効果を伴う自動意思決定。
3. 体系的監視 — 公共区域の観察、従業員の監視、ウェブトラッキング。
4. 機微なデータまたは高度に個人的なデータ — 特別カテゴリー、犯罪データのほか、金融、位置情報、電子通信も含む。
5. 大規模に処理されるデータ。
6. データセットの照合または結合 — 異なる管理者からのもの、または異なる目的のためのものを含む。
7. 脆弱なデータ主体に関するデータ — 子ども、従業員、精神疾患のある人、亡命希望者。
8. 革新的な利用、または新たな技術的・組織的ソリューションの適用 — AI、バイオメトリクス、IoT。
9. データ主体が権利を行使すること、またはサービス／契約を利用することを妨げる。

あらゆる DPIA の基礎は、実際にデータをどう扱っているかの正確な記述です。次を把握します。

• 性質 — 個人データのカテゴリー、取得元、受領者、保持、技術的セキュリティ、越境移転。
• 範囲 — データ量、データ主体の数、地理的および時間的な広がり。
• 状況 — データ主体との関係の性質、データ主体が有するコントロール、状況の機微性（職場、健康）。
• 目的 — 達成しようとしていること、意図する成果、事業上の価値。

これにデータフロー図を組み合わせます。自由記述の説明は、データフロー図が捉える事項を見落とします。

• 適法な根拠 — Article 6(1)(a)～(f)。特別カテゴリーの場合は Article 9(2) の条件も。
• 検討した、より侵襲性の低い代替手段 — より少ないデータ、匿名化データ、集約データ、またはより短い保持期間で目的を達成できないか？
• 目的の限定 — 各データカテゴリーは、明示された目的を真に支えているか？
• データ最小化 — フィールドの明示的なリストと、各項目について文書化された理由。
• 品質と正確性 — データを最新に保つ仕組みは何か？
• 保持と削除 — 法的／事業上の根拠を伴う正確な期間。
• 情報提供と権利 — データ主体にどのように情報を提供し、どのように権利を行使してもらうか？

特定可能な各リスクについて、次を文書化します。

• リスクの記述（明確で平易な言葉で）。
• リスクの発生源。
• 脅威が現実化する可能性（低／中／高）。
• データ主体への損害の重大度（低／中／高）。
• 総合的なリスクスコア。

日常的にカバーすべき脅威の種類：不正アクセス（内部者、外部の攻撃者）、改ざん（完全性の喪失）、喪失（破壊、利用不能）、差別、なりすまし、金銭的損失、評判の毀損、機密性の喪失、データに対するコントロールの喪失、仮名化データの再識別。

各リスクについて、予定される処理を特定します。

• 受容 — 残存リスクが許容可能。理由と承認者を文書化する。
• 低減 — 適用される管理策（暗号化、アクセス管理、研修、保持期間の短縮）。
• 回避 — リスクを除去するために処理を変更する（代わりに匿名化データを使用する、機能を取りやめる）。
• 移転 — 契約による割り当て（一次的リスクではまれ。保険やベンダー条項を通じた残存責任では一般的）。

予定される管理策の適用後に残存リスクを再スコアリングします。残存リスクが高いままである場合、処理を開始する前に監督機関に相談しなければなりません（Article 36）。

• DPO の助言（Article 35(2)） — DPO に相談しなければなりません。管理者は助言と異なる対応をとることができますが、その理由を文書化しなければなりません。
• ステークホルダーへの相談 — Article 35(9) は、適切な場合にデータ主体またはその代表者に相談することを推奨しています。
• 承認権限 — 通常はデータ管理者の上級の説明責任者（企業にとって重要な処理の場合は CISO、COO、または CEO）。
• 公表 — GDPR では義務付けられていませんが、ICO と多くの監督機関は、信頼のシグナルとして編集済みの DPIA 概要を公表することを推奨しています。
• レビューのサイクル — Article 35(11) は、処理活動が表すリスクに変化がある場合のレビューを求めています。少なくとも年1回のレビューをカレンダーに設定してください。

Article 36 の事前相談は、緩和策を適用した後も、権利および自由に対する残存リスクが高いままである場合に必要です。

監督機関が受領するもの：

• DPIA そのもの。
• 管理者および共同管理者／処理者の責任。
• 意図する処理の目的および手段。
• 措置およびセーフガード。
• DPO の連絡先。
• 監督機関が要求するその他の情報。

監督機関の回答期間：8週間（複雑な案件では6週間延長可能）。この期間中、承認なしに処理を開始することはできません。

シナリオ： ある物流会社が、ドイツとスペインの12拠点にわたる4,500名の倉庫作業員を対象に、顔認識ベースの出退勤打刻を導入する計画です。

閾値判定： 機微なデータ（識別のための Article 9 生体データ）＋大規模＋脆弱な主体（従業員）＋革新的な利用 ＝ 明らかに DPIA の領域。ドイツおよびスペインの監督機関のリストも、職場での生体認証による識別を必須 DPIA として挙げています。

記述（ステージ1）： 拠点入口の前面カメラから導出された顔テンプレート。拠点ごとの装置に保存された登録テンプレートと照合され、一致はタイムスタンプと作業員IDとともに記録される。生体テンプレートは在職期間＋30日間保持され、照合ログは3年間保持される。

必要性（ステージ2）： 適法な根拠は Article 6(1)(b) 雇用契約＋9(2)(b) 雇用法上の義務（ドイツ）および明示的同意（スペイン、労使協議会の共同決定を伴う）。検討した代替手段：PINカードスワイプ（却下 — なりすまし打刻）、NFC付きバッジ（却下 — 同様）、指紋（却下 — 衛生面）。代替手段に対する顔テンプレートの必要性を正当化。

リスク（ステージ3）： (a) 生体テンプレートの集中化が漏えいの標的となる。(b) 誤った不一致による賃金控除。(c) 機能の逸脱 — 打刻データが業績評価に使用される。(d) 従業員への強制：生体収集を拒否すると、より悪い条件への強制的なオプトアウトとなる。

処理（ステージ4）： (a) 拠点ごとのオンプレミス装置。テンプレートは HSM 管理の鍵で暗号化。クラウドへの複製なし。(b) 不一致時の手動オーバーライドワークフロー。給与計算は打刻失敗のみを理由に控除できない。(c) 契約上の禁止＋打刻データと人事業績システムの技術的分離。(d) 不利益のない真のオプトアウト経路（バッジによる代替）。労使協議会の合意書に文書化。

承認： DPO の助言を取得 — 顔テンプレートを退職後30日ではなく7日後に削除することを推奨。管理者が受け入れ。労使協議会の共同決定を取得。残存リスク：中～低。監督機関への相談は不要。

• 閾値判定を省略する。 DPIA を早めに実施したものの、後で必要なかったと気づくこと。その逆（実施せず、執行によって必要性が発覚する）の方がはるかに深刻です。
• 必要性を形式的な承認として扱う。 「検討した、より侵襲性の低い代替手段」は、規制当局が最も注意深く読むセクションです。形だけの言及は監査に耐えられません。
• リスク責任者の曖昧さ。 説明責任を負う者が指名されていないリスクは、未処理のまま残りがちです。
• データ主体への相談ステップの欠落。 適切な場合（従業員、大規模なユーザー基盤）、Article 35(9) の相談は防御可能性を高めます。
• 残存リスクの再スコアリングがない。 処理後に再スコアリングしなければ、Article 36 が発動されるかどうかを示すことができません。
• DPIA を一度きりの成果物として扱う。 重大な変更（新たなデータカテゴリー、新たな処理者、新たな管轄、新たな目的）は評価を再発動させます。
• エンジニアリング部門だけで DPIA を完成させる。 Article 35(2) はプライバシー専門家の関与を求めています。それがなければ、評価は法的根拠を欠きます。