財務報告統制の評価に当たっては、トップダウンアプローチが採られるということを既に記載した。しかしながら、ことIT分野に関しては、一部がボトムアップアプローチとなっている。その理由は不明である。経営者レベルのリスクの評価から、重要な会計処理に関するイベントが発生する業務プロセスに落とし込んでいき、重要な統制手続を識別していくまでは、共通である。
次に（というより同時に）、把握された重要な統制手続が人による運用されるものなのか、
情報技術のみにより運用されるものなのかを識別しなければならない。後者は通常はプログラムの中に書かれているので、聞き取りをしたり業務マニュアルなどを読んで理解していくしかない。
それら重要な統制手続のうちITの力を借りているものについては、ITがきちんと動いてくれることが前提である。さらにその前提として、プログラムの機能が仕様通りに作られて動き、人間がその機能をチェックしていること、そしてプログラムやデータが改竄されたりしないよう保障される環境が必要である。前者が業務処理統制、後者が全般統制と言われるものだ。
このように、全般統制のテストが必要かどうかは、そのIT基盤が重要な統制手続を担っているかどうかを把握した上で判断されるため、一部ではあるがボトムアップなアプローチとなっている。
しかしながら、本来の発想はやはりトップダウンのはずである。すなわち、経営戦略レベルからどの業務にどのようなリスクがあるのかを想定した上で、機能別にIT基盤を捉え、個々の基盤ないしは複数の基盤が一体となってITが本来担うべき統制手続を、データの正確性・完全性の観点と、会計処理の適正性という観点で、把握していくことが必要だ。
但し、把握された「あるべき統制」が全てITとして備わっていなければならないということではない。ITに備わっていないものでもともと設計されていないものは「仕様」なのだから、人間がカバーしなければならないのである。つまり、ITの仕様が期待している人間による統制手続をきちんとおさえておく必要がある。ボトムアップアプローチによった場合、ややもすると「それはシステムがやっている」としてあえて触れようとしないことがあるが、やはり業務側、システム側の双方から詰める必要があろう。
とはいえ、いくら「仕様」だからと言っても、常識的に考えてユーザが使いにくいとか、従来から改善要望が上がっているのに問題が残置されいるといった事象は、会社レベルでの統制の問題に発展することがある。つまり「仕様」は、その場の方便として通用するかもしれないが免罪符にはならないので注意が必要だ。
Tags: IT統制