RCMは何種類作るのか？――手続きと実態の両面から考える：Tips of SOX（1/2 ページ）

RCM（Risk Control Matrix）の作成は、膨大なエネルギーを要する。各部署からの情報も少ない段階であっても、変更を予測しながら、作業を進めていき、業務の手続き上の問題とその実態の両方の側面から統一を図っていくのがベストだ。

[平安彦，ITmedia]

RCM作成のポイント

　SOXに従事する中でRCM（Risk Control Matrix）は中心的な文書であり、作成し維持するのに多大な労力を必要とします。特に初年度は文書化プロジェクトを別途編成する場合も多いと思いますが、このRCMの作成に工数の多くを割くことになります。SOX対応のかなり初期の段階でRCMをどのように作成しどのように維持するのかを検討することになりますが、正直その段階では情報も経験も少なく、正しい判断をすることは難しいでしょう。むしろ現在考えている構成は変更されうると割り切って進めるべきなのです。

　その中でもいくつかの検討すべきポイントを述べたいと思います。以下については検討、若しくは議論されているでしょうか？

• RCMはシステムごとに作成するのか？
• RCMは誰が維持するのか？実際のシステム担当者なのか、または文書化の事務局など第三者がヒアリングなどを元に作成し維持するのか？

　上記について考えるべきことを順に説明しましょう。

RCMはシステムごとに作成するのか？

　RCMをシステムごとに作成するかどうかという問いについては、基本的にはそのようにすべきだ、というのが正解でしょう。なぜならリスクに対するコントロールは、個別システムによって異なる対応をされている場合が多いからです。IT全般統制のリスクで問われているコントロールに大きく2つに分けることができます。手続きに関する問題と実態に関する問題です。

　手続きとは開発案件の扱いに関する手続きやプログラムリリースに関わる手続き、システムの利用者IDの管理に関する手続きなどがあります。これはシステムが違っていても基本的な考え方に大きな違いはないでしょう。ですから実際に文書化をしてみると同じである可能性もあります。しかしいったんはシステムごとに文書化することをお勧めします。

　実際には些細な問題に見える部分が異なる場合も多く、またこの些細に見える部分が本質的なリスクに対応できていないことも考えられるからです。次に実態に関してですが、これはそれぞれのシステムにおいてリスクへの対応がどのように実装されているかというシステム自体に関する問いです。これはシステムの開発された時代やシステムの表面的性格から異なる実装になっていることが普通だと思われます。その時々で最適と思われる解を追求することが通常でしょうから、最近になるほどさまざまなリスクに対するコントロールが実装されていることでしょう。

　古いシステムではそもそも個人を特定するようなIDという概念がないようなシステムもあります。そのようなさまざまなシステムが持つであろう実態に関して問われている場合には、システムごとに文書を作成することは必須となるのです。

　ではそもそものあるべき姿に立ち返って考えるとRCMはいくつ作るべきなのでしょうか。これに対する回答は、「理想的には1つである。」が正解でしょう。本来リスクに対するコントロールはシステムに関わらず同一であるべきです。しかし前述のように時代背景やシステムの使用目的やコストなどによって実態は枝分かれしているのが実情でしょう。