解説
1 担当者にとって気になる？点
IT全般統制を評価する場合には、RCMが必要になります。
別のところで触れたトピックを、ここに切り出して説明します。
2 経理担当者に理解してほしい点
大手監査法人の監査マニュアルでは、法人間で若干違いがあるものの、最大で、以下の各区分を掛け算した量のRCMを作る必要があります。
Ａ） いわゆる会計システム、販売システム、購買システム、在庫受払システム、給与システムといったアプリケーションソフトごと
Ｂ） いわゆるプログラム変更管理・アクセス権限管理・ジョブ実行管理・障害管理・バックアップ管理といった区分の業務ごと
Ｃ） アプリケーションレベル・OSレベル・データベースレベルといったレベルごと
上記A）で対象とする「アプリケーションごと」とは、単に業務上利用している、存在しているアプリケーションのことを指すと理解することは誤りです。そうではなく、別のテーマのところで説明しました、「業務プロセスのキーコントロールに、ITに係る業務処理統制を選定した場合、当該アプリケーションごと」が正しいです。
そして、様式ですが、IT全般統制のRCMの特徴は、業務プロセスのRCMと異なり、リスクとコントロールの組み合わせが定型化されている点です。そのように定型化してしまっているというのがより正確な説明です。ですので、業務プロセスのリスク評価でよく言われる３点セット、すなわち業務記述書、フローチャート、RCMのうち前の２つは存在しないことが多いです。「アプリケーションのプログラム変更のRCM」のように、開発用のものとパッケージ用のものとで別パターンにする監査法人もあるようですが例外的な扱いはこれくらいです。
そして実務的には、上記のうち、リスク評価の結果、RCMは不要であると整理して、一部の作成を省略（正確には、統合）することが許容されています。
例えば、A）で特定のアプリケーションを省略する（したがってそれに対応するB）、C）のRCMを丸ごと省略する）例としては、いわゆるＥＲＰを使用している会社では、「各モジュールは構成要素に過ぎないので、プログラムは大きく１つ」という解釈をして、全体として１つの評価単位と整理してしまうことが通常です。
また、パッケージソフトの場合には、プログラムを自社で勝手に変更することは、メーカー保証が受けられなくなるデメリットがあるため、通常の会社ではあり得ませんので、プログラム変更管理についてはRCMで仔細に検討するまでもなく、財務報告リスクは無いと評価できる場合が多いでしょう。
3 念のため補足する点
以上は大手監査法人や準大手と呼ばれる、法人内に自前のIT専門家を抱えているクラスの監査法人の場合です。
それ以下の監査法人の場合には、、、、大手監査法人のOBの会計士が、自分が在籍していた監査法人の経験を踏まえて自らの判断で実施していると思われます。
が、大手監査法人の監査マニュアルは適宜更新されているため、それらOBの方のIT全般統制のRCMは古いかもしれません。
また大手監査法人のOBの会計士がいない監査法人では、そもそも自前で監査用のRCMをコストをかけて開発することも難しいのが現状であり、会社側がコンサルティング会社といっしょになって作ったJSOX用のRCMを、逆に財務諸表監査に流用していることが多いようです。
【経理担当者にとって】
IT全般統制のRCMの本数は、それなりに多い。
