前回に引き続き、NIST Privacy Framework（以下PF）における、個別のFunctionについて書いていきます。自分が検討する過程で躓いた所や、調べてみて理解が深まった所に重点を置いて書いていくので、これからPFを使う皆さんの参考になれば嬉しいです。
0.目次
- 総論
- IDENTIFY-P
- GOVERN-P
- CONTROL-P
- COMMUNICATE-P 本稿
- PROTECT-P
- 番外編 Tier評価
1.Function
下から２番目、緑色で表示されているのが今回取り上げるCommunicate-Pです。IPAの日本語訳では「伝達」と翻訳されると思います。NIST PF初期案ではInform（通知）という名前で定義されていましたが、最終的にはCommunicateという名前に落ち着きました。この辺後段で詳述します。
出典：NIST
Control-PとCommunicate-Pの類似点／相違点
前回Control-Pで書いたものと共通です（→参考：Control-P）。
Functionの名前
冒頭でご紹介した通り、本Function名は"Inform"から"Communicate"に変更されたました。GDPR→CCPAから来るプライバシーに関する議論の盛り上がりを踏まえ、Informと言う言葉から想起される一方向性を嫌ってCommunicateに変更されたのではないかと（私は）考えています。
Communicate-P – Develop and implement appropriate activities to enable organizations and individuals to have a reliable understanding and engage in a dialogue about how data are processed and associated privacy risks.出典：NIST
上記は最終的に確定したCommunicateの定義です。結構いい定義ですよね。実際規定されている内容も、企業側が一方的に通知をしておけば良いと言うものではなく、誠実にユーザーとコミュニケーションを行い意思疎通を行うことが求められています。
2.Category
NIST PFではCommunicate-Pに紐づくCategoryとして、以下の2つが挙げられています。今回は数が少ないので理解しやすいですね。
- Communication Policies, Processes, and Procedures
- Data Processing Awareness
"Communication Policies, Processes, and Procedures"で原理原則的なルールを定め、そのルールに基づき"Data Processing Awareness"で相互理解や対話に繋げていきましょうと言う立て付けです。
Communicate-PのCategory数が少ないのは、他のCategoryに比べて歴史が浅いからかなと言う気はします。今後「相互理解や対話のためには何が必要か」と言う議論が深まると、"Data Processing Awareness"の細分化・詳細化が進むのだと思います。
3.SubCategory
出典：NIST
今回は直近で「印象的な出来事」があったこともあり、"Data Processing Awareness"に含まれるSubcategoryにフォーカスして書いてみようと思います。
(1)印象的な出来事
規約づくりの専門家
との強ワードで注目を集めた日経の記事、及びその後に行われたData Signさんのランチタイムトークです。日経の記事では国内/海外の企業についてプライバシーポリシーの評価が行われ*1、ランチタイムトークではその裏話やあるべきプライバシーポリシーについて議論がなされていました。
(2)論点のピックアップ
ここでは2つ論点をピックアップして検討してみようと思います。
・規約のわかりやすさ
これは主に日経の記事でスコープが当てられていた部分です。
日経の取り組みでは規約のわかりやすさを
- 読みやすさ
- 理解しやすさ
- 検証しやすさ
で評価していました。
・規約の対等さ
こちらは逆に、ランチタイムトークで橋詰さんがより強い問題意識を持たれているようだった部分です。（なお時間の関係でこちらを掘り下げたお話は無し）
(3)NIST PFにおける解決方法
・前提
NIST PFを使う上で注意したほうが良いのは、規約の実質面（内容の妥当性）と形式面（読みやすさ）の評価をきちんと分けることだと思います。実質面としては
CM.AW-P1: Mechanisms (e.g., notices, internal or public reports) for communicating data processing purposes, practices, associated privacy risks, and options for enabling individuals’ data processing preferences and requests are established and in place.
あたりが主として手当をしています。また、形式面としては
CM.AW-P2: Mechanisms for obtaining feedback from individuals (e.g., surveys or focus groups) about data processing and associated privacy risks are established and in place.
あたりが主として手当をしています。プライバシーに関する取り組みについて、しっかりフィードバックを受けましょうと言う内容ですね。
・規約のわかりやすさ
橋詰さんご紹介のベストプラクティスは非常に素晴らしく、同社のプラポリを同僚に紹介した時も高い評価を得ていました。一方で、デザイン的知見を有してたイケてるLegal Tech企業ならではだな…と思う部分もありました。
日経で「わかりにくい」と評価されてしまった企業は一足飛びにベストプラクティスを目指すのではなく、まずはCM.AW-P2の取り組みとしてユーザーやデザインファームからフィードバックを集めて改善点を探っていくのが良いのではないでしょうか？
・規約の対等さ
NIST PFで実質面をより掘り下げた項目として、以下があります。
CM.AW-P8: Individuals are provided with mitigation mechanisms (e.g., credit monitoring, consent withdrawal, data alteration or deletion) to address impacts of problematic data actions.
上述のCM.AW-P1は各国法で必須の義務となっていることが多い（目的の通知とか）印象ですが、こちらのCM.AW-P8は一歩進めてプライバシーインパクトの高い領域について（企業が自主的に）ユーザーにオプションを提示する取り組みなんかが主として当てはまると思います。
どちらかといえばプライバシーの専門家が専門性を発揮すべきはこちらだし、ここの検討を疎かにしたまま「わかりやすさ」でお茶を濁すようでは本末転倒だと思っています。
--------------------------------------
以上です。
実務におけるCommuniacte関連の取り組みには、CS的要素が含まれるため対立が先鋭化しやすく非常に難しいなと感じています。「プライバシー的な専門性」と「CS的な専門性」は一部重なる部分もあるかもしれませんが、基本的には別物ですからね。
この点についてプラバシー的な専門性からアプローチするのであれば、やはり事前的・組織的対策に重点を置いていくのが良いのかなと感じています。この辺りはあまり整理できていないので、また機会があれば記事にします。
*1:なお私の所属先企業も評価対象に入っていますが、現行プライバシーポリシーの作成には関与していないのでそこまで個人的な感情は入っていないと（自分では）思っていますし、ご指摘はもっともだと感じる部分もあります。
