内部統制プロジェクトの運用テスト

集めたサンプルに、例えば承認した証拠が残っているかどうかを調査します。

運用テストを開始する前に、不備が見つかった場合の対処方法を決めておかなければなりません。不備の割合がある閾値を超えた場合、さらにサンプル数を増やして調査するか、キー統制が有効ではないと判断して改善項目としてあげるか、と言うようなことです。

また、そのキー統制が、アプリケーション統制の場合、どのように調査をするかも決めなければなりません。アプリケーション統制は、ITを活用することによって統制が効いているとしているものです。

アプリケーション統制の運用テストは、IT全般統制が有効である場合は、サンプル数は1つでよいとされています。IT全般統制が有効でない場合は、マニュアル統制と同様な数のサンプルを収集して調査します。

例えば、自動仕訳をしているので、仕訳を間違うリスクは排除できるとしている場合、仕訳前と仕訳後を比較してそのとおりになっているかどうか確かめなければなりません。

少々厄介なことが、アプリケーション統制では起こります。承認、あるいは確認した事実が残っていない場合です。例えば、レポートを画面に表示させ、その数値が合っていることを確認すると言うような場合です。また、ワークフローを活用して現場が申請書に入力後、上長の承認を得て、経理に回している場合にも、上長承認の記録が残っていない場合もあります。

業務の効率を考え、このような場合、合っていることが確認できたというような文書は残していないのがほとんどです。

そのアプリケーションのログが残っているではないか、というような反論を思い浮かべる読者の方もいると思います。
しかし、ログを何日分残していますか？例えログが残っていても、それは、画面で見たという証拠にはなっても、承認した、確認したという証拠にはなりません。

ITをフルに活用している企業でさえ、日本版SOX法に対応する内部統制構築では、業務効率を落とさなければならない場合もあります。ペーパーレスで業務を行っている場合でも、紙で証拠を残さなければならない場合もあります。

このような場合の、改善（改悪？）をどのようにするか、頭を悩まさねばなりません。どのような改善にするかは、別紙面に譲ります。

さらに、ある機能は、アクセス制限を設けており、担当者しか実行できないというようなキー統制の場合も問題です。一般に、アクセス権は、○○さんがこの機能を使用できるというように設定はできるのですが、××さんは使用できないというような設定ができないからです。

SAP R/3の場合、プロファイル、アクティビティ、権限値という階層で権限を設定しますが、その組み合わせが膨大になり、非常に厄介です。ここでも、IT全般統制が効いてきます。

そういう意味で、ERPを導入していれば、内部統制が万全であるという主張がありますが、決してそうではありません。過去に、ERPを導入すれば業務効率が上がるというような神話が横行していたのと同じです。