アドバイザリー

会社の環境に対応するためのIT全般統制 3つのヒント

2012.10.24

はじめに

平成20年4月1日以後開始する事業年度から内部統制報告制度が上場会社に導入されました。それを契機に、多くの会社では、IT全般統制を含む、財務報告に係る内部統制の見直しが行われました。
あれから数年が経過し、内部統制報告制度の導入の頃には適切に整備されていた内部統制も、その後の会社の内外の環境変化によるリスクの変化に対応できていない可能性があります。
このコラムでは、IT全般統制の評価において、評価対象となるIT全般統制が会社の環境に対応していないため問題となるケースを3つ例示して、改善策を検討します。

ケース1:緊急案件に対応していないIT全般統制

プログラム登録管理における統制上の要点として、「プログラムなどの本番登録に当たっては、システム部長が事前に承認し、本番登録申請書に承認印を押すこと」という内部統制が識別されていました。
しかし、監査人が本番登録申請書を閲覧したところ、システム部長の承認印は残されていましたが、押印日は本番登録日の翌日になっていました。そして、本番登録申請書上では、押印日が本番登録の翌日になった経緯が確認できませんでした。そのため、監査人が申請書の起票者に理由を問い合わせたところ、夜間に発生した緊急案件であり、システム部長には電話で事前に承認を得ていることがわかりました。

システム障害への緊急対応のために、承認権限者が不在時にプログラムの本番登録が必要となるケースは珍しくはありません。もし起票者の回答が事実であれば、システム部長の事前承認は実施されており、「不適切なプログラムが本番登録される」というリスクは低減されていると考えられます。しかし、システム部長による事前承認を第三者が客観的に確かめることができないことが、内部統制の評価上の問題となります。

このような問題を改善するために、緊急的な対応のケースを想定した内部統制のルールを整備・運用することが考えられます。具体的には、本番登録後の一定期間内(例えば、3営業日内)のシステム部長による承認印やその日付が本番登録後となった経緯(電話や電子メールによる事前承認の有無を含む)の記録が考えられます。

ケース2:組織の実態に対応していないIT全般統制

アクセス管理の統制上の要点として「ユーザーIDとアクセス権限の付与に当たっては、申請部署の部長以上の者が承認すること」という統制が識別されていました。
監査人がユーザーID登録申請書を閲覧したところ、申請部署の課長の承認の証跡は確認できましたが、部長以上の者による承認証跡は確認できませんでした。そこで、当該申請書の申請部署にその理由を問い合わせたところ、最近の組織改編により、当該部署には部長がおらず、部長以上は常務取締役になるため、多忙である常務取締役の指示で、通常の業務の承認は課長が実施することになっていることがわかりました。

このケースでは、承認権限者による承認が実施されていないことが、内部統制の評価上の問題となります。この問題点に対して、「今後はルール通り部長職以上(つまり常務取締役)が常に承認を行う」という改善策が思い浮かびます。しかし、常務取締役が多忙であることから、その実行可能性に疑問が残ります。

このケースでは、アクセス権限の重要度に応じた承認手続を導入するという改善策が考えられます。例えば、重要なアクセス権限の付与の申請については、従来どおり部長以上の承認を必要とするが、それ以外の重要性が低いアクセス権限の付与については、課長が承認すればよいというものです。アクセス権限の重要度に応じた管理手続に変更することにより、「重要なアクセス権限が職務分掌の観点から不適切な者に付与される」というリスクを高めることなく、内部統制の実行可能性を担保できると考えられます。

ケース3:IT環境に対応していない内部統制

会社は従来から自社でシステムの開発・保守を行っていたため、管理規程も自社開発・保守を前提としたものでした。そして、プログラム登録管理における統制上の要点として、「プログラムの変更においては事前にシステム部長が承認する」という内部統制が識別されていました。
ところが、会社はコスト削減効果を期待し、基幹システムをパッケージソフトウェアにリプレースしました。当該ソフトウェアは、ベンダーとの契約では、ベンダーがインターネット経由で当該ソフトウェアの保守を行い、プログラムの変更について月次で会社に報告することになっていました。そこで、プログラム変更における承認ルールを、システム部長による事前承認から、ベンダーからの月次報告の内容をシステム部長が承認することに変更しました。

このケースでは、ベンダーから月次報告を受けるまで、会社はプログラム変更の事実に気付けず、「不適正なプログラムが本番登録される」というリスクが月次報告まで低減されないことが、内部統制の評価上の問題になります。このリスクを低減するために、プログラム変更の都度、ベンダーから会社に報告を受けることが考えられます。しかし、契約に定めがない限り、プログラム変更の都度の報告をベンダーに要求することは難しいと考えられます。

このケースのようなIT環境の変更がある場合、当該変更が導入される前に、変更後のリスクに応じた内部統制を検討しておくことが必要となります。特に業務を外部に委託する場合、受託会社に必要とされる内部統制が契約の内容に反映されているか、受託会社の内部統制の評価をどのように実施するか(受託会社への往査や受託会社の内部統制の評価に関する報告書の入手の可否・要否を含む)を検討することが重要となります。

おわりに

会社の環境によって会社が直面するリスクは異なります。よって、財務報告に係る内部統制の整備・運用にあたっては、会社の環境を十分に理解した上でリスクを識別し、そのリスクを低減する内部統制を構築することが重要となります。そして、会社の環境の変化に応じて、内部統制を改善していくことが重要となります。
これらの点を十分にご理解して頂いた上で、このコラムが皆様の会社の内部統制の改善の参考となれば幸いです。





情報量は適当ですか?

文章はわかりやすいですか?

参考になりましたか?