やってみよう！PIA（プライバシー影響評価）！（報告編）
今回はPIA（プライバシー影響評価）実施後にどのような報告をすべきかについて説明したいと思います。
元米海軍データアナリスト（自称）。口癖はジャスティス。コスプレが大好き。
元プロボクサー。現役時代は「ハンマー・タコ」の異名で恐れられた。お酒が大好き。
イロイロとこじらせたまま中年になってしまった謎のイカ。ゲームが大好き。
ふんふん～♪
ヌルっと参上～♬ヌルっと解決～♪
なんやイカ君えらいご機嫌やな
だってPIA終わってひと段落したからさ
甘いで。まだ報告書も作成してないんやろ？
PIAは報告書の公表とかリスク対応計画の監視なんかも必要になるんやで？
じゃあ今回は報告フェーズの説明サクッとやるで！
PIAの全体プロセス（おさらい）
PIA全体には、準備、実施、報告といった3つのプロセスがあることを説明しましたが、今回は報告の部分にフォーカスして説明いたします。
| プロセス | 概要 |
|---|---|
| 準備 |
|
| 実施 |
|
| 報告 |
|
PIAの報告（6.5.1 報告書の作成、7 PIA報告書）
PIA報告のフェーズで重要になってくるのは報告書作成になります。
定められた範囲内での個人識別可能情報（以下「PII」という。）の取り扱い状況を報告するフェーズになりますが、ここで重要になるのは「誰に向けて報告するものなのか」「どこまで記載（開示）するか」になります。
例えば経営層向けに報告する前提であれば、技術的な要素の詳細な記載より、要点を簡潔に説明する記載が求められる傾向にあるため、場合によっては何パターンか作成する必要があるかもしれません。
また、記載の公開レベルについても詳細なPII取り扱いフローなどを公開してしまうと、悪意を持った人間に悪用されてしまうようなリスクも発生するため、記載内容と開示範囲も考慮する必要があります。
| プロセス | 概要 |
|---|---|
| PIA報告書の構成（7.2） |
|
| PIAの範囲（7.3） |
|
| プライバシー要件（7.4） |
|
| リスクアセスメント（7.5） |
|
| リスク対応計画（7.6） |
|
| 結論および意思決定（7.7） |
|
| PIAパブリックサマリ（7.8） |
|
PIAの報告（6.5.2 公表）
前項のPIA報告書をベースに利害関係者に公表するフェーズになります。
どこまでの情報をどのように公開するのかは組織の判断によりけりですが、一般公開用、内部関係者限り用ぐらいを用意しておくと応用が利くかと思います。
また、PIA報告書の登録簿を作成し、PIAの実施日時、範囲、報告書作成日等の情報をまとめておくと今後の継続改善や他所が実施する際の先行事例等に活用できるメリットがあります。
| PIA報告書（サマリ版）に記載されているといいかもリスト |
|---|
| プログラム、情報システムまたはプロセスの便益 |
| 処理および収集されるPIIの種類 |
| PII処理が行われる法域 |
| コンプライアンス分析の概要 |
| プライバシー要件を遵守するための組織が実施する予定または実施したプライバシーリスク対応措置の概要 |
| PII主体に推奨されるあらゆる措置 |
| PIAおよびプログラム情報システムまたはプロセスに責任を負う組織 |
| 責任を負うPII管理者の連絡先の詳細 |
| プログラム、情報システムまたはプロセスのために設置された利用者のプライバシーに関するヘルプラインまたはサポート機能の詳細 |
PIAの報告（6.5.3 プライバシーリスク対応計画の実施）
PIA報告書が組織として承認された後は、既に作成された「プライバシーリスク対応計画」などの計画実行フェーズに移ります。
前回説明した「PIAの実施（6.4.5.3 プライバシーリスク対応計画（管理計画、責任者承認、受容ステートメント等））」で作成した計画書に加えて、以下のような事項も考慮すると良いでしょう。
| PII処理の実装前にやっておくといいかもリスト |
|---|
| プライバシーに関連する教育もしくは訓練 |
| リスク対応等に係る予算の確保 |
| プライバシーポリシー、プライバシー取り扱い宣言書等の情報公開 |
| 定めたプライバシーリスク対応計画の実施もしくは見直し（計画書に記載されたリスク対応等の推奨事項が難しい場合として代替案や実装しない理由等を追記） |
| 推奨事項実施のモニタリング |
PIAの報告（6.5.4 PIAのレビューおよび/または監査）
このフェーズはPIA報告書をインプットとして、可能な範囲で第三者によるレビューもしくは監査を実施し、PIAが適切に実施されたかを検証する内容になります。
第三者が関わることでPIA報告書の信頼性や透明性の確保に繋がることから、何らかの法令遵守、自主規制、ガイドライン、監督機関からの要求、取引条件等が求められる場合に特に有効です。
また、リスク対応計画の適切性なども客観的に判断できることから、予め何らかのしきい値を定めたレビューもしくは監査を実施することも有効です。
PIAの報告（6.5.5 プロセスへの変更の反映）
PIA評価範囲内のビジネスプロセスもしくは情報システムなどに変更があった場合に、必要に応じてPIA報告書を更新する手続きを整備しておきます。
いわゆる「変更管理」を整備することで、変更による全体プロセスへの影響度などをリスクアセスメントし、影響の大きさによっては初期段階からのPIA再実施等も考慮する必要があります。
大きな変更点が無い状況が続いていたとしても、例えば情報システムの脅威や脆弱性は常に変化し続けることから、定期的なチェックもしくは第三者監査等を実施することも有効です。
情報システムにおける変更管理はITIL[2]やITSMS[3]などに基本的な考え方が記載されていますので、興味がある方はこちらもチェックしておくといいと思います。
……えー以上がザリガニ事業部で取り扱う個人情報であり、リスク軽減策として……
ふむふむ。うーん……えーと……
例えばだけど委託先管理は自主点検の報告書を受け取っているだけ？
結構機微データ預けているよね？最終委託先まで確認している？安全管理措置は？現場調査行った？
ウグ……えーと……あにょう。そにょう……
イカ君。ここは素直に受け入れてリスク分析と対応計画見直ししようや。
ありがたいコメントやで。
そう。別にイカ君個人を責めているわけではないのよ。
ちゃんとやっているのは分かっているから、頑張ってね！
おしまい
参考文献
- [1]ISO：ISO/IEC 29134:2017 “Guidelines for privacy impact assessment”
- [2]NTTコミュニケーションズ：意外と知らない？ITトレンド用語 ITILとは
https://www.ntt.com/bizon/glossary/e-i/itil.html - [3]情報マネジメントシステム認定センター：ITSMS（ITサービスマネジメントシステム）とは
https://isms.jp/itsms/index.html
- ※文中の商品名、会社名、団体名は、一般に各社の商標または登録商標です。