筆者はプライバシーマーク取得企業が実施したリスク分析で、効果を上げている事例をみたことがありません。審査基準にも問題がありますし、審査機関が推奨している様式にも問題があります。

まずは、リスク分析に関する審査基準を確認してみます。

上記の基準に基づいてリスク分析をすると、下表のような無意味なスプレッドシートをグルーピングした個人情報ごとに大量に作成することになります。

次に何をするべきかが浮かび上がってこない

信じられないことですが、要件を満たしていれば、このような無意味なリスク分析でも審査に合格することができます。

「２）個人情報のライフサイクル（取得、入力、利用、保管、廃棄等）に基づいてリスク分析を実施する」の基準が実はネックになっています。事業者はリスクを抽出するために業務フロー図を作成してみる等、色々と取組をおこないます。

読者からのお怒りを買うかもしれませんが、「業務フローを可視化すればリスク分析ができる」これは幻想なのです。
近年発生した情報漏えい事故を思い浮かべてください。委託先の常駐者が大量の個人情報をスマートフォンにコピーして持ち出した事故、標的型攻撃にあいファイルサーバ内のファイルを根こそぎ持って行かれた事故など。これらの事故につながったリスクは業務フローからは浮かび上がりません。

実は、業務フローから浮かび上がるリスクは「オペレーションミス」のみなのです。組織が抱える課題、情報システムが抱える課題、インフラ・ファシリティが抱える課題、これらを性悪説をベースで洗い出すのが余程有効です。
では、どうすればプライバシーマークの基準の中で、良いリスク分析ができるのか。簡単です。「当社にはどのようなセキュリティ上の課題があるのか？」というシンプルな問いを、自ら、あるいは関係者に投げかけてみてください。コンサルタントなどの専門家にファシリテートさせると、さらに効率的かつ効果的に課題の洗い出しをおこなうことができます。ここで上がってきた課題を「残存リスク」として認識します。

芯を食った「残存リスク」の認識が最も重要です。「不注意」や「確認漏れ」のような芯を外した「残存リスク」の認識は寧ろ有害です。（Pマークの審査員の中にはこのように芯を外した残存リスクの記載を要求するケースもあり、注意が必要です）

最後に、残存リスクを経営陣に報告し、優先順位付けも含めた会社としての対応を検討します。プライバシーマークでは求められていませんが、「リスク対応計画」を立案は必須だと考えてください。これがないとリスク分析は単なる自己満足に終わってしまいます。
 

＜関連情報＞
プライバシーマーク（Pマーク）に関心がある方はこちらへ
ISMS（ISO27001）に関心がある方はこちらへ