Privacy by Designに向けたPIAのすすめ

今日は、よく聞くようになった"Privacy by Design"を実現するために何をすればいいかについて、私なりの答えを提示してみようと思っています。また、共感してくれた皆さんには是非ご自身の会社で同種の取組みを行って欲しいと思っているので、テンプレートとして使っていただける資料も掲載します。

ここ数年持ち続けていた問題意識の総括として書いたので、最後までお読みいただけるととても嬉しいです。

 

f:id:seko-law:20200918150035p:plain

0.用語説明

PbD:Privacy by Design、プライバシーバイデザイン

エンジニアリングプロセス全体にわたってプライバシーを考慮するシステムエンジニアリングのアプローチ

PIAPrivacy Impact Assessment、プライバシー影響評価

個人情報の収集を伴う情報システムの企画、構築、改修にあたり、情報提供者のプライバシーへの影響を「事前」に評価し、情報システムの構築・運用を適正に行うことを促す一連のプロセス

1.背景

(1)GDPRの思い出

多くの人がGDPR対応に追われていた数年前、私もその渦中におりセキュリティ・プライバシーコンサルとして、オフィシャルなガイドラインも十分に整理されていない抽象的な法律とにらめっこしながら制度設計に明け暮れていました。

当時思ったのは大きく2つです。

  • 「なるべくDPIAをしなくて良いように整理する」*1って、気持ちはわかるけどそれユーザーの前で同じこと言えんの?
  • そもそも、PIA/DPIAがリスクコントロールの手段なのであれば、PIA/DPIAの実施対象を絞るべきではないのでは?工数は実施対象ではなく、実施項目や詳細度で調整すべき話では?

(2)現職での担当業務

そのようなコンサル時代を終え、私は今LINE株式会社に勤めているのですが、所属チームの名前はPIA(Privacy Impact Assessment)チームです。

そうです。LINE株式会社にはそのPIAをするためのチームが会社の中に存在し、そこに弁護士含めて一定数の人間を投入して(基本的には)自社の全サービスに対してPIAをかけているのです。自分の問題意識は正しかったのかもな…と、なんだか肯定してもらったような気がしました。

 (3)経済産業省のガイドブック策定

そんな中、今年の8/28に「DX時代における企業のプライバシーガバナンスガイドブックver1.0」という文書が経済産業省から出されました

PIAのことも第5章を使って書かれています。素晴らしいことです。

f:id:seko-law:20200918155507p:plain
(出典:経済産業省「DX時代における企業のプライバシーガバナンスガイドブックver1.0概要」)

ただ、同時に『これを見ても多くの人はあまりよくわからず、「明日からPIAやってみよう」とはならないだろうな…』とも思いました。

(4) ぼくのかんがえた…

であれば、人の資料にうだうだ文句付けるのもかっこ悪いし、自分で何か書いてみようかと思った時のツイートが以下です。 

 そして、そちらがある程度固まったので公表してみようというのが今日のブログです。

2.PIAレポートのテンプレート

こちらです。詳細はこの後「3.PIAレポートの使い方」で説明します。

Confluenceに入っていた「製品要件」というテンプレートをベースに、

  • コンサル時代のDPIAの経験
  • LINE株式会社でのPIAの経験
  • インハウスハブ東京法律事務所でのクライアントに対するPIAの経験
  • NIST Privacy Framework、GDPR、CCPA等各種フレームワークや法律の内容

を加味しながらまとめてみました。

 3.PIAレポートの使い方

(1)構成

冒頭にラベル的なサマリを置き、

  1. System / Product / Service overview
  2. Security / Privacy requirements
  3. Others

という章が並ぶ構成にしています。 Privacy by Design、すなわち開発の初期段階から関与することを想定しているため、冒頭のラベルに"Target release"があるのも特徴です。

表記が英語なのは、「NIST Privacy Framework、GDPR、CCPA等各種フレームワークや法律」と平仄を合わせるのに楽なためです。あとはなんとなくかっこいいというのもあります。

System / Product / Service overview

どの様な背景の下でそのシステム/プロダクト/サービスが必要とされ、ビジネスは何を目指しているのかを整理します。この章は以下でセキュリティ/プライバシー要件を検討する上での土台となり、制約条件として機能します。

"1.5.System configuration diagram"では本来システム構成図を書くのですが、今回はIPAの問題文(後述)に書かれている”事業スキーム”図で代用しています。

Security / Privacy requirements
  • 法律上の要求
    :2.1.Key legal provisions
  • リスクアセスメント上の要求
    :2.2.Data flow,2.3.Risk Management

 と、両観点を踏まえながら"2.4.Requirements"で必要なセキュリティ・プライバシー上の対応を導出します。 どちらかだけを検討するやり方もありますが、PIAレポートに情報を集約する観点からこのやり方が気に入っています。

"2.2.5.Data flow diagram"も本当はどの様なデータ項目が、どの様に環境を遷移していくのかを整理するものなのですが、今回はIPAの問題文に書かれている”事業スキーム”図で代用しています。

Others

ここまでで拾いきれなかった要素を拾ったり、更新履歴を記載したりします。

"Privacy by Design"と謳っている通り、PIAレポートは継続的に更新していくことが大切なので、更新履歴の管理も重要な作業です。

 (2)サンプルケース

PIAレポートの構成だけを示すのではあまり深い理解は得られないので、何らかケースを元にPIAレポートへの記載例も示したいと考えていました。一方で実際に自分が取扱ったケースを用いるのは守秘義務の関係でできないし、ゼロからケースを考え出すのはしんどい…

ということで、「一定程度背景事情が書き込んであるが、実在のケースでは無い」ものとしてIPAの論文試験の過去問を下敷きにすることにしました。程よく危なっかしい事例がよかろうということで、こちらの問2における冒頭から[新たな医療保険の概要]までを参考にしています。ヘルスケア関連のデータをリストバンド型のデバイスから取り込んで分析する話です。*2

--------------------------

以上です、アドバイス・ご質問・ご相談等々ございましたらTwitter(@seko_law)のDMやメール(shuhei.seko@inhousehub.tokyo)でご連絡いただけると喜びます。

*1:GDPRではPIAのことをDPIAと言っていると雑に理解していただければと思います。GDPRではリスクが高いとされる一定の要件に該当する場合にのみDPIAを行えば良いため、その要件の解釈も重要なタスクの一つでした

*2:本PIAレポートのサンプルは、当該IPAの問題を解説するものではありません。また、問題についても私は何の関係もありません。