個人情報保護の特異性
ビジネスにおける個人情報の利活用が当たり前となっている昨今、個人情報保護はもはや企業にとっての義務と言えます。2024年にも個人情報に関する様々なインシデントがあり、発生させた企業は改善対応や本人への対応のための直接的なコストの他、社会的評価の低下といった間接的なコストという形でも代償を支払っています。
しかし、こと個人情報の場合、その他の一般的な機密情報とは「インシデント」の範囲が異なるように思えます。例えば2024年に発生したKADOKAWA社のランサムウェア被害事例などは、個人情報の漏えい（を伴う）インシデントでした。これは情報セキュリティの3要素であるCIAのC（機密性）に該当するものであり、個人情報以外の機密情報であったとしても似たような被害となることが想定されるものでしょう。
一方で、例えば2019年に発生したリクナビの内定辞退率問題や、2013年に発生したSuicaデータの社外提供に関する問題などについては、いわゆる「漏えい」といったものではなく、CIAには、あるいは「真正性」「責任追跡性」「否認防止」「信頼性」を加えた7要素に当てはめてみても、直接的には該当しないものです（広く解釈すれば、同意のない第三者提供は漏えいと同じとも考えられますが）。
これは「個人情報保護」のスコープに、情報の保護（情報セキュリティ）のみでなく、プライバシーの保護の要素が含まれることが関係します。リクナビやSuicaの事例は、情報セキュリティ観点のインシデントというよりは、プライバシー保護観点のインシデントであると言えます。情報セキュリティ上の脆弱性などがあったわけではなく、サービスの開発・企画段階でプライバシー保護の観点が欠如してしまったということが、これらのインシデントの根本原因です。 であるならば、個人情報保護を実現するには、単なる情報セキュリティ観点のリスクアセスメントではなく、プライバシー観点でのリスクアセスメントも必要となります。そうした中で昨今重視されているのがPIAです。
PIAとは何か
PIAとはPrivacy Impact Assessmentの略で、日本語では「プライバシー影響評価」と訳されます。
PIAは元々「環境影響評価」と呼ばれる環境保全に関する事前評価手法などを基に考案されたもので、1990年代後半からカナダ・オーストラリア等で、公的機関が運用する情報システムにおいて実施されたのが始まりとされています。
その後2008年にはISO 22307として国際規格化、さらに2017年にはより具体化された内容がISO 29134として国際規格化し、日本でも2021年、ISO 29134をベースにJIS X 9251が制定されています。
JIS X 9251において、PIAの定義は、
個人識別可能情報の処理に関する潜在的なプライバシー影響の、特定、分析、評価、協議、伝達及び対応の計画を立てるための全体的なプロセスであって、組織のより広範なリスクマネジメントの枠組みに組み込まれたもの。
とされています。
ここで重要なのは、個人情報保護法で定義される「個人情報」ではなく、「個人識別可能情報（PII：Personally Identifiable Information）」がスコープとなっている点です。
PIIは日本における「個人情報」よりも範囲が広く、例えば「個人関連情報」なども含まれます。元々PIAが欧米で生まれた考え方であり、例えばGDPRで定義される「Personal Data」の範囲が日本の「個人情報」よりも広いことなども踏まえると、これは当然の帰結と言えるでしょう。
またPIAの便益についての文脈では、「早期に注意を促す仕組み」、「プライバシー上の課題の早期特定」と、早期の実施が強調されています。JIS X 9251以外でも、例えば個人情報保護委員会が発行している「PIA の取組の促進について」では、事業やシステムの設計段階で、事前に個人の権利利益の保護を組み込む「プライバシー・バイ・デザイン（Privacy by Design）」を実践するための手法と位置付けられています。
まとめるとPIAとは、「（個人情報よりも幅広い）PIIをスコープとして、プライバシー・バイ・デザインを実践するため、早期にプライバシー上の課題を特定し、分析・評価の上、社内で伝達・協議して、対応計画を立てるリスクマネジメントプロセス」と言えそうです。
ちなみに「早期に」というのが重要なのは大前提ですが、JIS X 9251においては新規のPII処理業務やシステムのみならず、既存の業務・システムに対しての実施や、継続的な実施（PIAの更新）も勧められています。
なお、上記の通りPIAの枠組みとしては「対応計画を立てる」ところで終わっています。これはあくまで「アセスメント」の枠組みだからですが、実務上は当然、立てた対応計画を実施することも必要です。実際JIS X 9251では「PIAのフォローアップ」として、PIAおよび対応計画の実施状況の監査なども組み込まれています。
ただし今回は文章量の都合上、「PIAの実施」に的を絞って、対応計画を立てるところまでの話としています。
PIAの実施プロセス
では「PIAを実施する」とは、具体的にどのようなことを行うものでしょうか。JIS X 9251では、以下のプロセスを規定しています。
それぞれについて簡単に解説します。
PIAの準備
① PIAの必要性の決定（しきい値分析）
新たなPIIの処理業務やシステムが発生した際のPIAの新規実施、プライバシー法制・社内規程・システム環境等の変化に応じたPIAの更新などについて、まずその必要性を決定することが求められています。この決定は組織のマネジメント層が実施します。JIS X 9251において、PIAの実施にはマネジメント層の「強力で持続的な関与」が約束されることが必要とされており、そのためにはマネジメント層主導で実施が決定される必要があります。
必要性を決定するためには、決定基準（しきい値）の設定が必要となります。
例えば関連する処理におけるPIIの件数や、有事の際のプライバシー影響の種類を基準とするといった方法が考えられます。こういった基準に照らし、PIAの必要性を決定します。
PIAが必要と判断される場合には、以降の項目に進みます。
② PIA チームの設置及び指示
PIAの実施が必要と判断された場合、まずはPIA実施の責任者（評価者）を任命します。
任命された評価者は、まずリスク評価基準、およびリスク受容基準を定義し、マネジメント層の承認を受けます。JIS X 9251では附属書Aとしてリスク評価基準を例示していますが、必ずしもこれに基づかず、組織が独自に定義しても構いません。
また評価者はマネジメント層と共に、PIAの実施要項および実施範囲を定義します。実施要項では、PIAの実施結果について利害関係者から意見聴取を行う必要性の有無、PIA報告書を提示する相手、PIAの予算および期間、PIA報告書またはその概要を公表するか否か、といった内容を明確化します。実施範囲では、PIAの実施対象となるプロセス・システム等を明確化します。
要するにPIAの実施概要を決めていくわけですが、評価者単独では判断が難しい場合もあります。そこでマネジメント層は必要に応じて、IT部門・法務部門・関連事業部門の代表者から構成されるPIAチームを構成し、評価者をサポートさせます。
③ PIA 計画の作成及びPIAを実施するために必要なリソースの決定
PIAの実施概要が決まったら、必要なアクション・PIAチームの各人の役割・実施スケジュール・利害関係者との協議が必要な場合はその方法等について、具体的な実施計画を作成します。
さらにこの計画に基づき、必要な予算および人的リソースを決定し、マネジメント層の承認を受けます。
④ アセスメント対象の説明
②で定めた実施範囲（プロセス・システム等）について、どのようなものであるかの詳細を評価者に説明させるプロセスです。例えばどのようなPIIを誰がどのように処理するか、関連するシステムの設計や運用状況、関連する情報機器の管理・運用状況といった内容を評価者に説明させます。
これにより、アセスメントにおいて考慮すべき事項を明確化します。
⑤ 利害関係者のエンゲージメント
ここではPIAの対象となるPII処理に関する利害関係者を特定し、利害関係者との協議によるフィードバックを得ることが求められています。
利害関係者は「PIIを処理する可能性又はPIIの処理によって影響を受ける可能性がある」者とされており、PII主体はもちろんのこと、従業者やビジネスパートナー、また場合によっては例えば消費者団体などの、PIAに関連する適切な関心をもっている他の組織なども含まれ得ます。このように様々な観点を考慮し、まずはどのようなカテゴリの利害関係者がいるのかを特定します。
利害関係者を特定したら、協議のための計画を策定します。もちろん全利害関係者と協議するのは難しいため、可能であれば利害関係者のカテゴリ毎に代表者となる個人を特定し、協議対象とします。計画では協議の規模（どの範囲の利害関係者と協議するのか）やスケジュール等を決めますが、協議の規模はプライバシーリスクと相関性があることが求められています。従って、PIAの実施で特定されたリスクに応じて計画の修正が必要となる場合もあります。 その後、計画した協議を実施することとなります。JIS X 9251では協議の実施まで含めて「PIAの準備」の中で記載されていますが、実態としては特定されたリスクに対する分析結果や対応措置に関してフィードバックを受けることが想定されるため、PIAの実施と並行して協議を行うこととなるでしょう。
PIAの実行
⑥ PII の情報フローの識別
ここからがPIAの実施となります。このプロセスでは、④で説明させた内容をベースに、評価者が実態を調査し、PII処理のフローを明確化します。これが以降のリスク特定のベースとなるため、様々なプライバシー法制の規制内容を考慮に入れながら、可能な限り詳細に可視化することが求められます。
⑦ ユースケースの内容分析
PIA対象のシステムの利用者について、どのような利用を行う（可能性がある）かを調査します。特に以降のリスク特定のため、意図しない結果をもたらす可能性のある利用者の行動を含めて検討する必要があります。
⑧ 関連するプライバシー安全対策要件の決定
このプロセスでは、④・⑥・⑦の結果を踏まえて、安全対策要件のリストを作成します。リスクアセスメントのためのベースライン策定、といったイメージです。
安全対策要件の作成にあたっては、各種のプライバシー法制や契約上の要求、情報セキュリティ管理策などを考慮する必要があります。
⑨ プライバシーリスクのアセスメント
⑧で作成した要件をもとに、対象となるプロセス・システム等のリスクアセスメントを実施し、リスクを特定します。
特定すべきリスクとしては以下のようなものが挙げられていますので、⑧の要件を作成する際にも意識するのが良いと考えられます。
| ・ | PIIへの認可されていないアクセス（機密性の喪失） |
| ・ | PIIの認可されていない変更（完全性の喪失） |
| ・ | PIIの紛失，盗難又は認可されていない持ち出し（可用性の喪失） |
| ・ | PIIの過剰収集（運用管理の喪失） |
| ・ | PIIの認可されていない又は不適切なひも付け |
| ・ | PIIの処理目的に関する情報が不十分（透明性の欠如） |
| ・ | PII主体の権利への考慮の欠如（例えば，アクセス権の喪失） |
| ・ | PII主体の認識又は同意なしにPIIを処理すること |
| ・ | PII主体の同意なしに、第三者とPIIを共有又は目的を変更すること |
| ・ | PIIの不必要な長期保有 |
こうして特定したリスクに対して、②で決定したリスク評価基準に基づきリスクの分析・評価を行います。このあたりはISMSにおけるリスク分析と似ており、影響度と発生可能性を定量的に評価し、対応の優先順位付けを行うことが求められています。
なお、この影響度と発生可能性の評価結果として、プライバシーリスクマップという形で図解することが求められています。イメージとしては下図のようなものです。
⑩ プライバシーリスク対応の準備
リスクを特定し、対応優先順位付けも完了したら、リスク対応計画を策定します。
ここはほとんどISMSの枠組みと変わらず、リスクの低減・保有・回避・移転から対応措置を選択し、適切な管理策（リスク対策）を特定し、対応計画を立案する流れとなります。
PIA実施の意義
ここまでPIAとは何か、どのようなものかについて見てきました。その上で、PIAを行う意義は何でしょうか。
一部の組織については、法的義務対応のためというのも考えられます。日本の個人情報保護法ではマイナンバーを取り扱う行政機関や自治体で「特定個人情報保護評価」として実施が義務付けられています。
またEUのGDPRでは、プロファイリングを含む自動化された処理に基づく評価で重大な影響を与える決定がなされる場合など、プライバシー影響の大きなPII処理について、DPIA（Data Protection Impact Assessment）として実施が義務付けられています。
しかし、これらはあくまでごく一部の事例であり、少なくとも多くの日本企業においては、PIAを実施する法的義務はありません。
それでもPIAを行う意義は何でしょうか。
筆者としては、PIAの肝は、単なる自社内でのリスクアセスメントではなく、PII主体視点でアセスメントを行い、結果に透明性を持たせることで、納得感を持ってPIIを預けてもらう、ということにあると考えています。前節「PIAの実施プロセス」の②・⑤の太字箇所を改めて見てください。PIAにおいてはPII主体を含む利害関係者の意見が非常に重要視されていることが分かるはずです。
例えばスマートシティなど、非常に広範なPIIの利活用を伴うビジネスは今後さらに増加すると考えられます。そういった中で、PII主体の納得感を獲得・維持することは、もはやビジネスの根幹であると言っても過言ではありません。その手段として、適切なPIAの実施は非常に有効であると考えられます。
当社ではこの度、PIAの実施を支援するコンサルティングサービスを開始しました。
PIIの積極的な利活用を進めるにあたって、PIAの実施に興味をお持ちいただけましたら、是非下記のお問い合わせフォームよりご相談ください。
