複数の子どもを持つ親なら、たいてい一度は、歯を食いしばりながらこう口にしたことがあるだろう。「どうして2人は仲良くできないの？」。そこには、仲良くすることは可能で、しかも簡単だという暗黙の前提がある。互いに優しくしさえすればいい。実に単純だ。
しかし、きょうだいがいる人なら、それがそうではないと知っている。岩のコレクションの一件もあれば、誕生日の封筒から20ドルが消えたこともある。
それでもなぜか、その同じ相手が、あなたが母親のお気に入りの花瓶を割ったときにアリバイを作ってくれ、ハロウィーンのお菓子まで分けてくれたりする。あなたは、たとえ渋々であっても、彼らをそばに置いておくことにする。
プライバシーとセキュリティのチームも、しばしば似たような関係に行き着く。インシデント時に互いを巻き込み、同じ四半期レビューに参加し、ときどき同じメールにCCを入れる。経営層はそれを「コラボレーション」と呼ぶが、実態は「調整」に近い。そして、それは成熟したプログラムを体現しているとは言い難い。
この統合が最も重要な意味を持つのは、データインベントリ、ベンダーレビュー、社内ポリシーの3領域である。
データインベントリ
同じ思い出をきょうだい2人に語らせると、まったく異なる2つの話が返ってくる。プライバシーとセキュリティのチームも、データをめぐって同じ問題を抱え得る。どのようなデータが存在し、どこに置かれているのかについての共通理解は、多くのプログラムがつまずく地点である。
設計上、この地図に対する両チームのアプローチは異なる。
・セキュリティチームは、組織が保有するデータとその保管場所に焦点を当て、適切に保護することを重視する。
・プライバシーチームは、そのデータで何が行われているかに焦点を当てる。どのように収集され、どう利用され、誰と共有されているのか。
この2つの視点が分断されたままだと、各チームは全体像の半分しか持てず、調整はできても真の統合には至らない。成熟したプログラムは両者を1つのインベントリに統合し、2つの次元を同時に捉える。そうすることで、インシデント対応、権利行使要求、ベンダーのオンボーディングに向けた、より完全で効率的な基盤ができあがる。
自社のプログラムがどこにあるのかを見極めるには、次を問うとよい。収集した内容（およびその方法）、保管場所、利用目的、共有先、そして保護のために実装されている技術的コントロールを示す単一の記録を、チームが引き出せるか。答えが「別々のツールを確認する必要がある」「別々のチームに聞く必要がある」であれば、インベントリは統合されていない。
ベンダーレビュー
きょうだいの例えに戻ると、家事分担をきょうだいに任せれば、それぞれが自分には妥当に見えるリストを作成するが、相手のものとはまったく異なるものになる。同じベンダーを評価するセキュリティとプライバシーのチームも、同様の問題に直面し得る。
・セキュリティのベンダー評価は、暗号化、アクセス管理、セキュリティ認証、インシデント履歴といった技術的コントロールを評価する。
・プライバシーのベンダー評価は、データフローや契約上の義務を評価する。たとえば、ベンダーがアクセスできる個人情報の範囲、その利用方法、サブプロセッサーの関与の有無、そしてプライバシー法に準拠しつつプライバシー権利の要求を支援できるかどうかである。
ベンダーレビューをサイロ化したアプローチで行うと、同じ取引関係についての部分的な視点が2つ生まれるだけで、リスクの統一された全体像が得られない。たとえばISO 27001やSOC 2のようなセキュリティ認証は、ベンダーに適切な保護措置があることを確認するが、そのベンダーが個人情報をどのように扱うのか、あるいはプライバシー法上の義務を満たせるのかについては、ほとんど何も語らない。
より効果的で成熟したプログラムは、評価基準を1つのレビューに統合し、リスクスコアリングを組み合わせる。そうすることで、セキュリティの保護策とプライバシーの実務を、同じ枠組みで評価し、是正できる。
連携の成熟度を診断するには、ベンダーリスク評価が、セキュリティの保護策とプライバシー上の義務の双方を、単一のアウトプットとして捉えているかを問うべきである。セキュリティとプライバシーのチームが共有のスコアリングや是正プロセスなしに別々のレビューを行っているなら、プログラムは調整されているだけで、統合されていない可能性がある。
社内ポリシー
長いドライブで後部座席を共有した経験があるきょうだいなら、「後部座席では自分の側から出ない」という言葉が、関係者それぞれにとって別の意味を持つことを知っているだろう。プライバシーとセキュリティのチームにとっての社内ポリシー課題も、同様である。
データ分類、インシデント対応、ベンダーのオンボーディングといった領域では、プライバシーとセキュリティの双方が、社内ポリシーの書き方に利害を持つ。だが、それらのポリシーが孤立して策定されると、組織は一貫性のない指針を抱えることになる。
その例がデータ分類ポリシーだ。設計上、両チームは機微なデータを異なる基準で定義する。
・セキュリティチームは、事業にとって重要、または高リスクであるものに基づき機微なデータを定義する。知的財産、財務記録、認証情報などである。
・プライバシーチームは、プライバシー法が求めるものに基づき機微なデータを定義する。これには、正確な位置情報、健康データ、子どものデータなど、法的義務が強化され得るカテゴリが含まれる（あわせて注記すべきは、プライバシー法には、必ずしも社内の定義と一致しない独自の定義が存在し得るという点である）。
データ分類がこの2つの視点を織り込まない場合、追加の法的保護やセキュリティリスクを反映できない可能性がある。同じことは、プライバシー通知要件を見落とすインシデント対応手順、あるいはセキュリティ基準は満たすがプライバシー上の義務評価を欠くベンダーのオンボーディングプロセスといった、他の共有ポリシーにも当てはまる。
こうした相違を統一されたポリシーへとすり合わせ、組織全体の従業員が、どのデータに追加の注意が必要で、なぜそうなのかについて、一貫した指針に基づいて動けるようにすることが重要である。
自社のセキュリティのデータ分類スキーマと、プライバシー上の機微データの定義を並べてみてほしい。カテゴリ同士が対応しないなら、チームは異なる基盤から仕事をしており、その上に構築されるポリシーもそれを反映することになる。
「仲良くする」から「一体で機能する」へ
多くのきょうだいは、いずれ何らかの共通点を見いだす。岩のコレクションの一件はお決まりの冗談になり、ハロウィーンのお菓子の争いは遠い過去となり、仲良くすることは努力から「当たり前」へと変わっていく。
私の経験では、プライバシーとセキュリティのプログラムも同じ道筋をたどる。仕事の進め方そのものにコラボレーションが組み込まれるよう、作業を構造化することで到達できるのだ。統合されたインベントリ、統一されたベンダーレビュー、共有されたポリシーの基盤は、問題を先回りして見越すプログラムと、問題に対応するだけのプログラムを分ける。そしてそれは、機能するプライバシーとセキュリティの関係と、ただ仲良くしているだけの関係との違いである。
