今回は番外編として、NIST Privacy Framework（以下PF）のアセスメント担当者がTierの評価を行う際に躓きやすいポイントについて書いてみます。コンサル時代を通じて、実際に自分が躓いたポイントを抽象化して書いていくので、PFを利用する多くの方に参考にしていただけるのではないかと思っています。*1
※このシリーズ初見の方は以下の目次から「総論」に飛んでいただけると嬉しいです。
0.目次
- 総論
- IDENTIFY-P
- GOVERN-P
- CONTROL-P
- COMMUNICATE-P
- PROTECT-P
- 番外編 Tier評価 本稿
1.前提
NIST PFではTier（成熟度のようなもの）を4段階で評価していることは、これまでにも何度か述べました。
Tier1：Partial → 個別的で受動的な対応
Tier2：Risk Informed → 暗黙知に基づく対応
Tier3：Repeatablez → 形式知に基づく対応
Tier4：Adaptive → 継続的改善に基づく対応
今回はこれを前提に、各要求事項がどのTierに当たるか評価する際のポイントを書いていきます。
2.Tier評価のポイント
アセスメント担当者の方はまず自分で暫定案を作成し、それを経営層に報告するというプロセスを踏むと思います。そこで以下場合を分けをして説明します。
(1)自分で評価する段階
まず最初、アセスメント担当者が要求事項のリストを見ながら暫定的な評価を自分で行う段階を想定します。ここでは、各要求事項についてAs-Isの評価をどのように付けるべきか悩むと思います。
Tier3 or Tier 4の判断
一番悩みが少ないのはTier3なのかTier4なのかの判断だと思います。
Tier3なのかTier4なのかで悩むということは、おそらく関連規程が既に存在すると思うのでその規程の「更新履歴」および「更新内容」を確認します。ここで更新が形式修正*2しかなされていないならTier3です。
一方でTier4に該当するような場合は、日々の業務で生じるLessons learnedなんかが随時規程に反映されているはずなので、当該文書の管理主体（会議体だったり、担当者だったり）が明確に存在することが多いです。
Tier2 or Tier 3の判断
Tier2なのかTier3で悩むケースは…
- 規程みたいなフォーマルな文書は存在しないが、（社内wikiなどで）文書化はされてるがこれってTier2なのTier3なの
みたいなケースが多いと思います。このような場面ではひとえにその文書が
formally approved and expressed as policy.
（NIST PF Appendix E: Implementation Tiers Definitions）
と言えるかにかかっています。
もっともここで注意したいのは、「必ずしも社内wiki（Tier2）より規程（Tier3）が優れている訳ではない」ということです。文書の格が上がっていくにつれて修正容易性や閲覧数が下がっていきますからね。この辺はNISTが「必ずしも全ての項目でTier4を目指すべきものではない」みたいなことを言っている所以だと思います。
Tier1 or Tier 2の判断
一番難しいところです。
ここは最早会社としてどのように判断し意思決定するか、という話だと思っています。詳しくは「(2)経営層に報告する段階」で説明します。
(2)経営層に報告する段階
アセスメント担当者は、どこかの段階でアセスメント結果を経営層に報告することになると思います。その際によく出くわすご指摘について、パターン別に説明します。
【ご指摘A】
「何も対応してない」って評価になってるけど、XXXで対応してるんじゃないの
具体例を用いて説明します。多くの組織はPDCAサイクルがPDPDサイクルになりがちで、以下の項目が苦手です。
GV.MT-P6: Policies, processes, and procedures incorporate lessons learned from problematic data actions.
出典：NIST
そのため当該項目はTierが1になるケースも多いと思うのですが、経営層からは
- 必要があればXXXって会議体で検討しているし、そのことは規程で文書化されている。Tier3ではないのか。
とのご意見をいただくことが多くあります。 この辺りは要求事項側の抽象度を上げていけば当然「XXXの会議体で対応できている」と評価することになります。なので、ご指摘も間違いという訳ではありません。
しかしNIST PFは認証を取る類のものではなく、セルフアセスメントをして気づきを得るためのツールです。拡大解釈をしてTierの評価を上げていくことは本質的ではないのですが、防御的になってしまう経営側の心情も理解できるので難しいところです。
このような状況では、NIST PFの使い方を丁寧にご説明するのが大事だと考えています。
【ご指摘B】
Tier2となっているが、その根拠をもっと明確に示してほしい
TierについてはNIST PFの Appendix Eに定義が書いてあります。Appendix Eでは評価の観点として
- Privacy Risk Management Process
- Integrated Privacy Risk Management Program
- Data Processing Ecosystem Relationships
- Workforce
の4つが示されており、各Tierでそれぞれの観点についてレベル感が示されています。
出典：NIST
これらは非常に参考になる情報ではあるのですが、それぞれの要求事項についてどの観点を採用する/しないかや、どのような割合で比重を置くかなどは定められている訳ではありません。ここで各Tierの分類定義をぎちぎちと詰めていっても不毛です。
むしろ、「自社としては◯◯という観点を重視してここはTier2と判断する」といった形で意思決定を行なっていくこと、そして早々にTo-Beの議論に移るのが生産的だと思います。
3.まとめ
初期のGDPR 対応（ガイドラインが全然出揃っていない段階）の経験がある方は共感いただけると思いますが、「決まっていないものについて、答えが出るのを待っていても仕方ない」「自社としてどうリスク判断するかが大切だ」と、上の人が理解してくれるかが大きな分かれ目だと感じます。
ここが上手くいかず、Tierの評価に対する不信感がNIST PF全体への不信感に繋がったりするとプロジェクトは大抵失敗し、To-Beや具体的な施策の検討に繋がりません。なので、報告前に経営層の理解を得ておくことが非常に重要だと思います。
--------------------------------------
以上です。
私は（前職含め）担当したNIST CSFやPFのプロジェクトが全てが成功した訳ではなく、経営層報告で共感をえられないまま失敗したものもあります。これを読んだ皆さんが本記事を参考に上手く経営層報告を切り抜け、具体的な施策に繋げられることを祈っています。
