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

内部統制整備プロジェクトも佳境に入ってきました。
ウォークスルーを行い、キー統制を決めました。
キー統制について、それが有効に働いているかどうかを確かめるために、運用テストを行います。
運用テストは、キー統制で行われた証拠資料を収集し、不備がないかを確かめます。
キー統制が行われる頻度によって、集めるサンプル数が異なります。
統計的に、年度で1度行われるものは、サンプル数1、月次で複数回行われるものは、サンプル数25~60というのが一般的なようです。


集めたサンプルに、例えば承認した証拠が残っているかどうかを調査します。
運用テストを開始する前に、不備が見つかった場合の対処方法を決めておかなければなりません。不備の割合がある閾値を超えた場合、さらにサンプル数を増やして調査するか、キー統制が有効ではないと判断して改善項目としてあげるか、と言うようなことです。
また、そのキー統制が、アプリケーション統制の場合、どのように調査をするかも決めなければなりません。アプリケーション統制は、ITを活用することによって統制が効いているとしているものです。
アプリケーション統制の運用テストは、IT全般統制が有効である場合は、サンプル数は1つでよいとされています。IT全般統制が有効でない場合は、マニュアル統制と同様な数のサンプルを収集して調査します。
例えば、自動仕訳をしているので、仕訳を間違うリスクは排除できるとしている場合、仕訳前と仕訳後を比較してそのとおりになっているかどうか確かめなければなりません。
少々厄介なことが、アプリケーション統制では起こります。承認、あるいは確認した事実が残っていない場合です。例えば、レポートを画面に表示させ、その数値が合っていることを確認すると言うような場合です。また、ワークフローを活用して現場が申請書に入力後、上長の承認を得て、経理に回している場合にも、上長承認の記録が残っていない場合もあります。
業務の効率を考え、このような場合、合っていることが確認できたというような文書は残していないのがほとんどです。
そのアプリケーションのログが残っているではないか、というような反論を思い浮かべる読者の方もいると思います。
しかし、ログを何日分残していますか?例えログが残っていても、それは、画面で見たという証拠にはなっても、承認した、確認したという証拠にはなりません。
ITをフルに活用している企業でさえ、日本版SOX法に対応する内部統制構築では、業務効率を落とさなければならない場合もあります。ペーパーレスで業務を行っている場合でも、紙で証拠を残さなければならない場合もあります。
このような場合の、改善(改悪?)をどのようにするか、頭を悩まさねばなりません。どのような改善にするかは、別紙面に譲ります。
さらに、ある機能は、アクセス制限を設けており、担当者しか実行できないというようなキー統制の場合も問題です。一般に、アクセス権は、○○さんがこの機能を使用できるというように設定はできるのですが、××さんは使用できないというような設定ができないからです。
SAP R/3の場合、プロファイル、アクティビティ、権限値という階層で権限を設定しますが、その組み合わせが膨大になり、非常に厄介です。ここでも、IT全般統制が効いてきます。
そういう意味で、ERPを導入していれば、内部統制が万全であるという主張がありますが、決してそうではありません。過去に、ERPを導入すれば業務効率が上がるというような神話が横行していたのと同じです。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*