先日のエントリーでクリップした記事内に「スプレッドシート統制」の話が出ましたが、財務報告に係る内部統制(J-SOX)の整備・構築作業の中ではどちらかと言えば後回しにされがちな分野です。「(企業側も監査人側も)そこまで手が回らない」というのが一つの理由と推測されますが、もう一つスプレッドシート統制(用語としては以下「エンドユーザーコンピューティング(EUC)統制」と呼びます)の性質そのものに起因するのではないかと思われます。
J-SOXの制度では、各種引当金勘定などの決算・財務報告に係る固有の業務プロセスの中では、その会計数値の計算・集計・分析・加工や仕訳作成などに関する作業の多くはエクセルシートを活用した運用となっています。重要な決算処理の過程で利用しているツールにも関わらず、その管理は担当者個人に委ねられているケースも少なくありません。
決算・財務報告プロセスを例にあげたのは、実際にこの領域で財務諸表に誤りが発見されることも多く、その原因を分析していくと内部統制に起因していると結論づけられてしまうことが多いからです(内部統制以外の原因であると言いにくいともいえます)が、それよりも上流の会計情報生成プロセスにおいても同じことが言えます。
内部統制の観点からは、担当者等によるスプレッドシート、データベース管理ソフト等を利用した作業に対して適切な上席者がレビュー・承認することと、EUCの観点から計算式の誤りなど虚偽記載につながる可能性についての検証やアクセス制御などを実施することが重要になります。
エンドユーザー自身がシステム管理責任者になるということ
通常の業務系のシステムや会計システムの運用であれば、情報システム部門がシステム管理規程などを定めてそれに従ってシステムを構築・運用していきます。情報システム部門はそれ自体が役割でありますので自分たちの仕事として取り組みます。
これがEUCでは現場で実際に業務を行うエンドユーザ自身がシステム管理責任者の役割を担わなければなりません。それはシステムの利用者であるユーザ自らが業務システムを構築し、その運用に直接携わるのがEUCである以上自然な流れではあるのですが、エンドユーザの本来業務ではありません。かといって情報システム部門は構築されたシステムに関与していないので引き取ることもできないのです。このEUCの性質そのものにEUC統制の整備がしにくい理由があります。
情報システム部門に移管するのもリスク対応
EUCの観点からそのシステムを評価した場合、財務報告を作成するうえでよほど重要なシステムであるならば、EUCではなくしてしまう、つまり会社の資産として情報システム部門に管理責任部署を移管してしまうことが考えられます。こうすることによりスプレッドシートやデータベース管理ソフトで、処理を自動化するマクロや小規模なプログラムの作成・保守が情報システム部門において、その他の情報システムと同じプロセスで管理してもらえます。実現可能かどうか別として、発想を変えることでリスクが低減されます。
EUCの取扱いポリシーは必要
確かにEUCとしてスプレッドシートやデータベース管理ソフトで構築された業務上のシステムの管理責任部署を情報システム部門に移管することは難しいかもしれません。単純な四則演算の数式しか入力されていないスプレッドシートも多いですし、そもそも何のためにEUCにしたのか(ユーザが自由に情報を利用・活用するためではなかったのか)といった話もあります。
そこでEUCに対して何らかのリスク対応をしなければならないという前提のもと、EUC統制において情報システム部門とユーザの役割分担を次のように捉えるのが現実的な対応として考えられます。
- 情報システム部門が、会社としてEUCに関する取扱いのポリシー(原理原則)を定めること
- ユーザ部門が、そのポリシーに従ってシステムを構築・運用すること
EUCに関する取扱いポリシーにはEUCの定義、適用範囲、評価の範囲、評価の方法などを記載します。