GDPR DPIA:データ保護影響評価はいつ必要か?(2026年版)

DPIAは、規則(EU)2016/679第35条に基づき、処理が自然人の権利および自由に高いリスクをもたらす可能性がある場合には常に必要となる。管理者は、処理が開始される前に、その後ではなく、評価を完了しなければならない。

規則の全体像についてはGDPRとは何かを参照されたい。コンプライアンスプログラムを構築している場合、GDPRコンプライアンスチェックリストはより広範な義務をカバーしており、GDPR DPO要件は、DPIAについて助言するデータ保護officerをいつ任命しなければならないかを説明している。

GDPRにおけるDPIAとは何か

データ保護影響評価とは、データ管理者が計画中の処理業務によって生じるプライバシーリスクを特定・評価し、それらのリスクを許容可能な水準に低減するための措置を決定する、構造化され文書化されたプロセスである。規則(EU)2016/679第35条(1)は、この義務を次のように定義している。「特に新しい技術を用いる種類の処理であって、処理の性質、範囲、状況および目的を考慮して、自然人の権利および自由に高いリスクをもたらす可能性が高い場合、管理者は、処理を行う前に、想定される処理業務が個人データの保護に及ぼす影響の評価を実施しなければならない。」

DPIAは、指令95/46/ECの下での事前通知制度に代わるものである。前文89はこの転換を説明している。GDPRは「通知の一般的義務」を撤廃した。なぜなら、包括的な登録は、保護を確実に改善することなく行政上の負担を生じさせていたためである。その代わりに、規則は真に高いリスクを生じさせる処理業務の一部に規制当局の注意を集中させる。

この義務は管理者にある。処理者は支援することができ、第28条(3)(f)は特に、処理者が「第32条から第36条の義務の遵守を確保するにあたり管理者を支援する」ことを要求しているが、法的義務は管理者のみに帰属する。

DPIAは一度限りの作業ではない。第35条(11)は、管理者に対し、「処理業務が示すリスクに変化があったとき」には少なくとも評価を見直すことを要求している。設計時には低リスクと評価された処理も、技術、規模、データカテゴリー、または利用状況が変化することにより、高リスクとなり得る。

DPIAはいつ義務となるか:高リスクの閾値

トリガーとなる条件は、処理が個人に「高いリスクをもたらす可能性が高い」ことであり、これは予測的かつ将来を見据えた基準である。管理者は、そのようなリスクが発生する可能性を評価しなければならず、害が実際に発生するまで待ってはならない。新しい技術は第35条(1)において特に言及されているが、それはまだ評価されておらず、確立された実務によって統治されていないリスクを生じさせる傾向があるためである。

第35条(3)は、DPIAを本質的に義務付ける3つの明示的なカテゴリーを規定している。これらは下限であって上限ではない。第35条(3)に列挙されていないその他の種類の処理も、第35条(1)の一般的な高リスク基準を満たす場合にはDPIAを必要とし得る。

第35条(3)(a):法的効果または同様に重大な影響を伴う体系的な自動プロファイリング

第35条(3)(a)は、「自動処理(プロファイリングを含む)に基づく個人の側面の体系的かつ広範な評価であって、自然人に法的効果を生じさせる、または自然人に同様に重大な影響を及ぼす決定がそれに基づいてなされるもの」についてDPIAを要求している。3つの要素が同時に存在しなければならない。すなわち、評価が体系的かつ広範であること、処理が自動化されていること、そして結果として生じる決定が法的効果(権利または法的地位の変更)または同様に重大な影響(雇用の拒否、給付からの排除、財務条件の実質的悪化)を生じさせることである。

前文71は具体的な例を挙げている。オンライン与信申込み、自動化された採用選考、保険の価格設定モデルである。このカテゴリーはまた、予測的取り締まりにおけるアルゴリズムによるスコアリング、人間によるレビューなしに顧客のアカウントをブロックする自動不正検知、差別化が重大である行動ターゲティング広告のパイプラインもカバーする。

限定原理は「法的効果または同様に重大な影響」である。ウェブページの色を変えるパーソナライゼーションや、結果を伴わないプレイリストの推奨は、この閾値には達しない。

第35条(3)(b):特別カテゴリーまたは犯罪歴データの大規模処理

第35条(3)(b)は、「第9条(1)で言及される特別カテゴリーのデータ、または第10条で言及される犯罪歴および犯罪行為に関する個人データの大規模な処理」についてDPIAを要求している。特別カテゴリーには、人種的または民族的出自、政治的意見、宗教的または哲学的信条、労働組合員資格、遺伝データ、一意の識別のために処理される生体データ、健康データ、性生活または性的指向に関するデータが含まれる。

大規模という限定語は重要である。前文91は、個々の医療従事者が自らの患者のデータを処理することは大規模処理には該当しないと説明している。WP248は、データ主体の数、データ項目の量または範囲、活動の期間、地理的範囲という4つの要素を考慮することを推奨している。地域ネットワーク全体で数十万人の患者記録を処理する病院システムは明らかにこの閾値を満たすが、数百人の患者を扱う個人開業医の診療所はこれに該当しない。

第35条(3)(c):公衆がアクセス可能な場所の大規模かつ体系的な監視

第35条(3)(c)は、「公衆がアクセス可能な場所の大規模な体系的監視」についてDPIAを要求している。前文91は、「特に光学電子機器を用いる場合の、公衆がアクセス可能な場所の大規模な監視」を例として挙げている。公共空間における防犯カメラシステムはその典型例である。この基準は、民間主体と公的機関の双方に等しく適用される。顔認識や歩容認識を用いる現代のビデオ分析は、まさにこのカテゴリーに該当し、第35条(3)(a)に基づく追加の検討事項を発動させる。営業時間中に手動で監視される小規模店舗内の単一のカメラは、大規模または体系的とはみなされにくい。自動分析と数週間にわたる保存期間を伴う、都市中心部にまたがる数百台のカメラのネットワークは、明らかにこれに該当する。

高リスクに関するEDPBの9つの基準

EDPBのWP248ガイドライン(2017年10月採択、2018年5月にEDPBが承認)は、第35条(1)の下での高リスクの可能性を示す指標として9つの基準を特定している。単独の基準が決定的となることはなく、EDPBの立場は、2つ以上を満たす処理はDPIAを必要とすると扱うべきというものである。

1. 評価またはスコアリング。 処理が、業務遂行能力、経済状況、健康、個人的嗜好、信頼性、行動、位置情報、または移動といった側面から、個人を評価またはスコアリング(プロファイリングおよび予測を含む)する。

2. 法的効果または同様の効果を伴う自動的な意思決定。 処理が、第35条(3)(a)にあるような、法的または著しく類似した効果を生じさせる自動的な決定を伴う。

3. 体系的な監視。 処理が、ネットワークを通じて収集されるデータや、従業員または消費者の秘密の監視を含む、個人の体系的な観察または統制を伴う。デバイスフィンガープリンティング、持続的なクッキートラッキング、ネットワークトラフィック監視、従業員監視ソフトウェアを含む。

4. 機微データまたは極めて個人的な性質のデータ。 処理が、第9条の特別カテゴリーデータ、第10条の犯罪歴データ、財務データ、位置データ、健康データ、その他悪用によって重大な害を生じさせ得るデータを伴う。EDPBは、金融取引データを高リスクの指標として特に挙げている。

5. 大規模に処理されるデータ。 特別カテゴリーだけでなく、あらゆる種類の個人データに対して、第35条(3)(b)の大規模という限定語を適用する独立した検討事項。

6. データセットの照合または結合。 処理が、2つ以上の異なる情報源からのデータを結合、相互参照、または照合し、各情報源が当初収集された際のデータ主体の合理的な期待を超え得る方法で行う。

7. 脆弱な対象者に関するデータ。 処理が、管理者に対して脆弱な立場にある個人、すなわち子ども、従業員、患者、高齢者、庇護希望者を伴う。子どもは、「関係するリスク、結果および保護措置、ならびに個人データの処理に関する自らの権利についての認識が低い」ため、特に言及される。

8. 新しい技術的または組織的解決策の革新的な利用。 処理が、より広範な社会的または個人的影響がまだ確立されていない新規な方法で技術を適用する(IoT、生体認証、AI、接続デバイス)。

9. データ主体が権利を行使すること、またはサービスを利用することを妨げる処理。 処理が、データ主体が権利または正当な期待を有するもの、すなわち銀行口座、政府給付、医療、雇用、住居へのアクセスを付与するか拒否するかを決定する。

各国監督機関のDPIAブラックリスト

第35条(4)は、各国内監督機関に対し、「第1項に基づきデータ保護影響評価の要件の対象となる処理業務の種類のリストを作成し、公表する」ことを義務付けている。これらのブラックリストは、その管轄区域内で法的拘束力を有する。複数のEU/EEA加盟国で事業を行う管理者は、トリガーとなるカテゴリーが異なり得るため、関連する各国内当局のブラックリストを確認しなければならない。

第35条(5)は、監督機関がDPIAを必要としない処理の種類のホワイトリストを公表することも認めている。ホワイトリストの項目が提案された業務をカバーする場合、特定の事情により当該業務が一般的な高リスク閾値を超えない限り、DPIAは不要である。

第35条(6)の一貫性メカニズムは、提案されたリストが「複数の加盟国におけるデータ主体への商品もしくはサービスの提供またはその行動の監視に関連する処理、または連合内での個人データの自由な移動に実質的な影響を及ぼす可能性のある」処理に関わる場合に適用される。この場合、当局は第63条の一貫性メカニズムを使用しなければならず、これによりEDPBがそのプロセスに関与することになる。

一部の国内当局からのブラックリスト項目の例:フランスのCNILは、職場における生体アクセス制御、公共部門における社会的リスクの予測スコアリング、大規模な健康データ処理、雇用主データベースと福祉給付データベースの自動照合を含めている。ドイツのデータ保護会議は、体系的な従業員行動データ処理、大規模な患者健康記録、AI主導の与信評価を含めている。英国のICO(英国GDPR)は、子どもの大規模プロファイリング、従業員通信の体系的監視、職員認証のための生体データ、複数情報源にわたる行動プロファイルを列挙している。

管理者は、要約に頼るのではなく、関連する各監督機関が公表している現行のリストを確認しなければならない。リストは、EDPBが新たなガイダンスを採択したり、各国当局が新技術に対応したりするにつれて更新される。

DPIAが含まなければならない内容:第35条(7)

第35条(7)は、最低限の内容要件を定めている。評価には、WP248で拡張されている4つの要素が「少なくとも」含まれなければならない。

4つの必須要素に加え、WP248は、管理者およびDPOの身元・連絡先、データ主体および個人データのカテゴリー、保有期間、DPOがどのように協議されたかの記録、評価日および予定されるレビュー日の文書化も推奨している。

DPIAは作業文書である。「適切な措置が講じられている」と主張するだけの2ページの要約は、要件を満たさない。EDPBの立場は、規則が特定の方法論を義務付けているわけではないが、CNILのプライバシー影響評価方法論、ISO 29134、またはBSI規格200-2のような、構造化され再現可能な方法論を反映すべきというものである。

DPIAの責任者は誰か

管理者は、DPIAを実施し、その内容の正確性および完全性について法的責任を負う。これは、処理者やDPIAコンサルタント業者との契約によって委譲することはできない。

第35条(2)は、管理者に対し、「データ保護影響評価を実施するにあたり、指定されている場合はデータ保護officerの助言を求める」ことを要求している。これは協議義務であり、責任の移転ではない。DPIAにおけるDPOの役割は第39条(1)(c)に列挙されており、これはDPOに対し、「求めに応じてデータ保護影響評価に関する助言を提供し、本条に基づくその実施を監視する」ことを要求している。管理者がDPOの助言を無視する場合、その理由を文書化すべきである。

第35条(9)は、管理者に対し、「想定される処理についてデータ主体またはその代表者の見解を求める」ことを奨励している。これはベストプラクティスの推奨であり、義務要件ではないが、消費者向け製品については、リスク特定の段階を強化し得る。

管理者が高リスク処理に用いる製品を構築する処理者は、間接的な利害関係を有する。第28条(3)(f)は処理者に管理者を支援することを要求しており、多くの処理者は現在、事前構築のDPIA文書やデータフローマッピングツールを契約上の成果物として提供している。

タイミング:処理が開始される前

第35条(1)は明確である。DPIAは「処理を行う前に」完了しなければならない。評価が完了し、リスクが評価され、緩和措置が講じられている(または残存リスクが高い場合は事前協議が完了している)状態で、管理者が処理を適法に進めることができると確信していなければならない。これらすべては、いかなる実際の処理が開始される前に行われなければならない。

管理者は、プロジェクトの日程にDPIAの完了を組み込まなければならない。稼働開始後に開始されたDPIAや、既に進行中の処理を書面上で正当化するために遡って作成されたDPIAは、要件を満たさない。監督機関は、事後的なDPIAを、第5条(2)のアカウンタビリティ原則が遵守されていないことの証拠として明確に批判してきた。

前文90は必要な順序を定めている。処理を設計し、DPIAを実施し、残存リスクが高い場合は監督機関に協議し、その後にのみ処理を開始する。

大規模な組織では、段階的なプロセスが一般的である。スクリーニング段階で、完全なDPIAが必要かどうかを判断する。スクリーニングが高リスクを確認した場合、処理設計が最終決定される前に完全なDPIAが続く。ICOとCNILはいずれも、完全なDPIAが不要であるという結論に至った場合でも、管理者がその結果を文書化するために使用できるスクリーニングテンプレートを公表している。

ステップバイステップのDPIAワークフロー

ステップ1:処理業務を特定し、DPIAが必要かどうかを確認する。 データの種類、対象者、目的、法的根拠、技術、保有期間、当事者を含め、想定される業務をマッピングする。3段階のテストを適用する。(a)当該業務は第35条(3)の義務的カテゴリーに該当するか。(b)監督機関のブラックリストは当該処理の種類をカバーしているか。(c)EDPBの9つの基準のうち2つ以上が該当するか。いずれかの回答が「はい」であれば、DPIAが必要である。結果はいずれにせよ文書化する。

ステップ2:DPOに協議する。 第35条(2)に基づき、DPOが任命されている場合、ステップ1の結果を共有し、方法論を確認するよう求め、予備的な法的懸念事項を指摘してもらう。協議の日付とDPOの回答を記録する。

ステップ3:処理を体系的に記述する。 以下をカバーする書面による記述を準備する。個人データのカテゴリーおよび量、影響を受けるデータ主体、収集方法、具体的な目的、第6条(1)に基づく法的根拠(特別カテゴリーが関与する場合は第9条(2))、収集から削除までのデータフロー、処理者・副処理者およびそれぞれとの契約関係、保有スケジュール、処理の管轄区域。

ステップ4:必要性および比例性を評価する。 各処理目的について、以下を評価する。目的が個人データなしに、匿名化または仮名化されたデータで、またはより少ないデータで達成できるかどうか。保有期間が必要最小限であるかどうか。法的根拠が適切に対応しているかどうか。処理がデータ主体の合理的な期待と整合しているかどうか。より侵害性の低い代替案が存在する場合、より侵害性の高い方法を選択した理由を文書化する。

ステップ5:リスクを特定し評価する。 処理の各要素について、個人への影響(権利を行使できないこと、身体的・経済的・評判上の害、差別的取り扱い、機密性の喪失、再識別、萎縮効果)、および既存の保護措置を考慮した発生可能性によって分類されたリスクシナリオを特定する。各シナリオについて、発生可能性評価、深刻度評価、既存の緩和措置を記録する。

ステップ6:緩和措置を特定し文書化する。 中程度または高リスクの各シナリオについて、追加の措置を特定する。技術的措置(暗号化、仮名化、データ最小化、自動削除、アクセス制御、監査ログ)および組織的措置(職員研修、処理者の契約上の義務、侵害対応手続、アクセスレビュー、プライバシー・バイ・デフォルト)である。各措置について、残る残存リスクを記録する。

ステップ7:全体の残存リスクを評価する。 特定されたすべてのリスクが低いまたは許容可能なレベルに低減されている場合、DPIAは処理を進める決定を支持する。いずれかのリスクシナリオが高い残存リスクを維持する場合、管理者はそれを低減するために処理を再設計するか、ステップ8に進まなければならない。

ステップ8:高い残存リスクが残る場合の監督機関への事前協議。 第36条(1)は、「第35条に基づくデータ保護影響評価が、管理者がリスクを緩和するために講じた措置がない場合に処理が高いリスクを生じさせることを示す場合、管理者は処理の前に監督機関に協議しなければならない」と定めている。処理は、当局が回答するか、協議期間が経過するまで開始できない。

ステップ9:DPIAを文書化し、承認し、記録する。 完成したDPIAは、リスクを受け入れる権限を持つ管理者または指定された代表者によって承認されるべきである。DPOが協議された場合、その助言と管理者の対応が記録の一部となるべきである。第5条(2)に基づくアカウンタビリティ文書として保管する。

ステップ10:レビュースケジュールを設定する。 第35条(11)は、「処理業務が示すリスクに変化があったとき」には少なくともレビューを要求している。文書自体にレビュー予定日を組み込む。中程度リスクの業務については通常12から24か月、高リスク閾値に近いものについては6から12か月である。技術、規模、データの種類、目的、受領国、または規制上の状況における重要な変更は、暫定的なレビューを発動させるべきである。

第36条に基づく事前協議

第36条は、緩和措置をすべて適用した後もDPIAが残存する高いリスクがあると結論付けた場合に発動する。管理者はその後、処理を進める前に監督機関に協議しなければならない。第36条(1)は義務的な「しなければならない」を使用している。

事前協議の要求を提出する際、管理者は第36条(3)に列挙されている資料を提供しなければならない。管理者と処理者それぞれの責任、想定される処理の目的および手段、データ主体を保護するための措置および保護措置、DPOの連絡先詳細、完成したDPIA、当局が要求するその他の情報である。

監督機関は、第36条(2)に基づき、書面による助言を提供するために最大8週間の猶予があり、特に複雑な処理についてはさらに6週間延長できる。協議期間中、当局は「第58条で言及される権限のいずれか」、すなわち正式な警告の発出、一時的な処理禁止の賦課、または違反手続の提起を用いることができる。

事前協議は規制上の事前承認やセーフハーバーではない。協議期間内に異議を唱えなかった監督機関は、処理を積極的に承認したわけではない。管理者はGDPR遵守について法的責任を負い続ける。ただし、完了した事前協議は、管理者が残存リスクを特定し、それを管轄当局に開示し、停止を指示されなかったという同時代の記録を作成する。

第36条(4)は、加盟国に対し、「処理に関連する国内議会が採択する立法措置の提案の準備中」に監督機関に協議することを義務付けており、これは同じ原則の公共部門版である。

必要なDPIAを実施しなかった場合の帰結

必要なDPIAを実施しなかったことは、第35条の直接的な違反である。第83条(4)に基づき、第35条および第36条の違反は、より低い行政制裁金階層、すなわち最大1,000万ユーロまたは全世界年間総売上高の2%のいずれか高い方の対象となる。制裁金は違反ごと、かつ拠点ごとに科される。

スペインのAEPDおよびハンガリーの監督機関は、いずれも高リスク処理についてDPIAが欠如していたことが列挙された違反の一つであった決定を下している。EDPBの年次報告書は、DPIAの遵守を、検査中に最も頻繁に特定されるギャップの一つとして挙げている。

直接的な制裁金リスクを超えて、DPIAの欠如は下流のアカウンタビリティ上の問題を生じさせる。明らかに高リスクの処理についてDPIAを提示できない管理者は、第5条(2)の遵守や、第24条(1)に基づく適切な技術的および組織的措置を実施する義務の遵守を証明できない。文書の欠如自体が、体系的な失敗の証拠となる。

第28条契約の下で運用される処理者は、DPIAプロセスへの協力を証明するよう管理者からますます求められている。データフロー、副処理者、セキュリティアーキテクチャを文書化できない処理者は、その管理者顧客にコンプライアンス上のギャップを生じさせる。

他のGDPR規定との相互作用

データ保護バイデザインおよびバイデフォルト(第25条)。 第25条(1)は、管理者に対し、データ保護原則の実施を目的とした措置を講じ、処理に必要な保護措置を統合することを要求している。DPIAは、高リスク処理についてそれらの措置が何であるべきかを特定するための主要なメカニズムであり、プライバシー・バイ・デザインのプロセスに直接組み込まれる。

処理活動記録(第30条)。 DPIAは第30条の記録と相互参照されるべきである。記録は目録であり、DPIAは高リスクの項目に対する詳細な検討である。

処理のセキュリティ(第32条)。 第32条(1)は、リスクに見合った水準のセキュリティを確保するための適切な技術的および組織的措置を要求している。DPIAのリスク評価は、第32条の分析にとって自然な基盤となる。これらを別個の作業として扱う管理者は、自らのセキュリティ評価がDPIAと矛盾していることに気づくことが多い。

特別カテゴリーおよび犯罪行為(第9条・第10条)。 第35条(3)(b)の義務的DPIAを発動させることを超えて、第9条・第10条に基づく適法な法的根拠のより狭いリストは、必要性および比例性の評価が、依拠する特定の第9条(2)の条件が処理のすべての要素に真に適用されるかどうかについて、より厳格に検討しなければならないことを意味する。

第三国への移転(第46条から第49条)。 処理がEU/EEA域外への個人データの移転を伴う場合、移転メカニズムをDPIAに文書化し、受領国における保護の十分性をリスク評価に組み込まなければならない。Schrems II判決(データ保護コミッショナー対Facebook Ireland LimitedおよびMaximillian Schrems、事件C-311/18、大法廷、2020年7月16日)は、標準契約条項に依拠する移転について管理者に移転影響評価の実施を要求している。その評価は、DPIAと統合されるか、DPIAから直接参照されるべきである。

免責事項: 本記事は、規則(EU)2016/679(GDPR)に関する一般的な法律情報を提示するものであり、法的助言を構成するものではない。GDPRは、30のEU/EEA加盟国にわたる監督機関によって解釈・執行されており、適用される要件は、貴社の処理の性質、事業を行う加盟国、規制ガイダンスおよび判例法の進展によって異なり得る。本ページの情報は、2026年6月時点で公式情報源に照らして確認されたものである。貴自身の状況に関する助言については、関連する管轄区域で有資格の弁護士またはデータ保護専門家に相談されたい。

よくある質問

GDPRの下でDPIAはいつ必要ですか?

第35条(1)に基づき、処理が特に新しい技術を用いる場合に自然人の権利および自由に高いリスクをもたらす可能性が高い場合、DPIAが必要となる。第35条(3)は、法的効果または同様に重大な影響を伴う体系的な自動プロファイリング、特別カテゴリーまたは犯罪歴データの大規模処理、公衆がアクセス可能な場所の大規模かつ体系的な監視という3つの場合にDPIAを義務付けている。管理者は、自国の監督機関が公表しているブラックリストも確認しなければならない。EDPBの9つの高リスク基準のうち2つ以上が満たされる場合、WP248の下でのEDPBの立場はDPIAを実施すべきというものである。

DPIAの実施責任者は誰ですか?

DPIAの実施について法的責任を負うのは管理者である。第35条(2)は、管理者に対し、指定されている場合は評価中にデータ保護officerに協議することを要求しているが、DPOの役割は助言的なものである。DPIAの正確性および完全性についての責任は管理者に残る。処理者は第28条(3)(f)に基づき管理者を支援しなければならないが、管理者の法的責任を引き受けることはできない。管理者は、第三者ベンダーを関与させることによってDPIA義務を外部委託することはできないが、プロセスを支援するために外部の専門知識を利用することはできる。

管理者が必要なDPIAを実施しなかった場合どうなりますか?

必要なDPIAを実施しなかったことは第35条の違反であり、第83条(4)に基づき最大1,000万ユーロまたは全世界年間総売上高の2%のいずれか高い方の行政制裁金の対象となる。直接的な制裁金に加え、DPIAの欠如は、第24条(1)に基づく適切な技術的および組織的措置を実施しなかったこと、および第5条(2)の遵守を証明できなかったことの証拠となる。検査や苦情処理を行う監督機関は、DPIAの欠如を日常的にコンプライアンス上のギャップとして特定しており、その欠如は単一の違反を、より広範な体系的なアカウンタビリティの失敗という認定へと転じさせ得る。

防犯カメラ監視にDPIAは義務ですか?

防犯カメラを用いた公衆がアクセス可能な場所の大規模かつ体系的な監視は、第35条(3)(c)の義務的DPIAトリガーに該当する。特定の設置が大規模かつ体系的の閾値を満たすかどうかは事実による。営業時間中に手動で監視される小規模小売店内の単一のカメラはDPIAを必要としにくいが、自動分析と長期の保有期間を伴う大規模な公共空間にまたがるカメラのネットワークは明らかに必要とする。管理者は自国の監督機関のブラックリストも確認すべきである。防犯カメラシステムが顔認識または生体分析を組み込んでいる場合、第35条(3)(a)および(b)も発動する。

GDPR第36条に基づく事前協議とは何ですか?

事前協議とは、すべての合理的な緩和措置を適用した後もデータ主体に対する高い残存リスクが残る処理を開始する前に、管理者が管轄の監督機関に通知し協議しなければならないプロセスである。第36条(1)に基づく義務は、DPIAが残存する高リスクを十分に低減できないことを確認した場合に適用される。管理者は、完成したDPIA、処理の記述、講じられている保護措置、DPOの連絡先詳細を提出しなければならない。監督機関は最大8週間の回答期限を有し、複雑な業務についてはさらに6週間延長できる。当局は、当該業務がGDPRに違反すると判断する場合、助言、警告の発出、または処理の禁止を行うことができる。

DPIAは監督機関に提出する必要がありますか?

通常は必要ない。DPIAは、管理者が作成し保管する内部のアカウンタビリティ文書である。提出が求められるのは2つの状況のみである。第36条に基づく事前協議が、DPIAが緩和不可能な残存する高リスクを明らかにしたことにより発動される場合、および監督機関がその検査または調査権限を行使してDPIAの確認を求める場合である。したがって、管理者はDPIAを、いつでも当局から要求され得る文書として扱い、詳細で、十分に文書化され、最新の状態に保つべきである。

1つのDPIAで複数の処理業務をカバーできますか?

できる。第35条(1)は「処理業務の種類」に言及しており、前文92は、DPIAが同様の高リスクを生じさせる一連の類似の処理業務を対象とし得ることを確認している。複数の同様の方法でデータを処理するプラットフォームをカバーする単一のDPIAは、評価が各異なる活動に関連する具体的なリスクに対応している限り、許容される。同様に、共有処理インフラを構築する公的機関や、共通の技術を導入する同一業界の複数の管理者も、各管理者が自らの特定の状況について共有評価を見直すことを条件として、単一のDPIAを実施できる。

DPIAはどのくらいの頻度で見直す必要がありますか?

第35条(11)は、管理者に対し、「処理業務が示すリスクに変化があったとき」には少なくともDPIAを見直すことを要求している。GDPR本文には固定の暦上の間隔はないが、WP248は、DPIA完成時にレビュースケジュールを設定することを推奨しており、中程度リスクの業務については通常1年から2年の間隔である。処理における重要な変更(新しいデータの種類、規模の大幅な増加、新技術、新たな目的、新しい受領国、または法的・規制上の状況の変化を含む)は、暫定的なレビューを発動させるべきである。管理者は、予定されるレビュー日をDPIA文書自体に記録すべきである。

DPIAに関するEDPBのガイダンス文書は何ですか?

主要なEDPBガイダンスはWP248rev.01「データ保護影響評価(DPIA)に関するガイドライン、および規則2016/679の目的のために処理が高いリスクをもたらす可能性が高いかどうかの判断について」である。これは第29条作業部会によって2017年4月4日に採択され、2017年10月4日に改訂され、2018年5月のEDPB第1回全体会合で承認された。WP248は、高リスクの9つの基準を定め、2つ以上の基準が満たされる場合に管理者がDPIAを実施することを推奨し、DPIAが含まなければならない内容を記述し、DPIAと事前協議との関係を説明している。全文はEDPBのウェブサイト(edpb.europa.eu)から入手できる。

GDPRのDPIA規則は処理者にも管理者と同様に適用されますか?

DPIAを実施する法的義務は、処理者ではなく管理者にある。しかし、第28条(3)(f)は、データ処理契約に、処理者が第32条から第36条の遵守を確保するにあたり管理者を支援する旨の規定を含めることを要求しており、これはDPIAおよび事前協議の義務を明示的に含んでいる。実務上、処理者は、自らのデータフロー、副処理者、セキュリティアーキテクチャに関する情報を管理者に提供しなければならない。高リスク処理に使用される可能性が高い製品を設計する処理者は、製品提供の一部として事前構築のDPIA文書やプライバシー影響評価テンプレートを作成することがますます期待されている。