経営者視点の内部統制　第6回　J-SOX対応プロジェクトの勘所（3）　ITへの対応

J-SOXの大きな特徴は、COSOフレームワークにおける5要素（統制環境、リスクの評価、統制活動、情報と伝達、モニタリング）に加え、「ITへの対応」を評価対象としている点です。

これが引き金になって、システム業界におけるいわゆるJ-SOX特需が起きたわけですが、そもそも経営者が「ITへの対応」をすることのメリットは何でしょう？

J-SOXでは、システムで自動化された処理については、機能変更がないとか、IT全般処理統制が有効である等の前提条件が揃った場合は、前年の結果が利用できるという利点があります。

J-SOXが毎年の継続的活動であることを考えると、前年の結果が再利用を可能にする自動化＝システム化は、会社にとって大きなコスト・セーブとなりますね。

では、「ITへの対応」について、経営者は具体的にどの部分に注意を払えばいいのでしょう？最終回となる本稿では、この点に焦点を当てていきたいと思います。

ITに対する統制活動は、IT業務処理統制とIT全般統制の2つからなり、両者が一端となって機能することにより、完全かつ正確な情報処理が確保できることになります。

ここで、IT業務処理統制とは、販売、購買、経理等の個々の業務プロセスを管理する情報システムに組み込まれたコントロール（統制）のことです。例えば「与信限度額を超えた受注は入力ができない」とか「承認がされていないと発注ができない」等の機能が挙げられます。

これに対し、IT全般統制とは、会社の情報システムが全体として信頼に足りうるものかを問題にしており、IT業務処理統制が有効に機能する環境を保証するためのコントロールを意味します。実施基準では具体例として、「システムの開発・保守」「システムの運用・管理」「アクセス管理とセキュリティ」「外部依託に関する契約」の４つを挙げています。

以上を図式化すると次のようになりますが、経営者にとって注意を払うべきは「IT全般統制」であることは明らかです。ここでは、「IT全般統制」を構成する主要４項目について、説明してまいります。

【IT統制の枠組み】

システムの開発とは、文字通り新規にシステムを構築すること。これに対し、システムの保守とは、不具合（バグ等）を修正したり、機能を追加・改良したりすることですが、両者に求められるコントロールは基本的に同じです。

具体的なコントロールについての説明に入る前に、この分野のIT全般統制が整備されていない場合、財務報告の信頼性にどのような影響が生じるか、以下に例を挙げてみます。

• 開発されたシステムに対するテストが不十分であったため、在庫管理システムと会計システムの間で在庫数が一致せず、財務情報の正確性が保てなくなった。
•  保守契約を結ばずにパッケージの会計システムを導入したところ、会計基準の変更があったにもかかわらずソフトウエアの更新が行われず、財務情報が不正確になった。
• 未承認のプログラム変更による不具合が発覚し、財務報告の数字を変更する必要が生じた。

こうした事態を防ぐためのコントロールは、「開発（変更）要件の承認」「テストの実施」「開発（変更）結果の承認」という至極当り前のものです。しかしながら、情報システムの導入において失敗事例が多いことを見ると、この当たり前の全般統制ができていないという事実を認識しておくべきです。

特に「新しいシステムによって何を実現させ、何をやらなくてよいか」を明確にしていない場合は、開発途中で次々の要件変更が生じてしまい、カスタマイズ箇所の増大、延いては開発コスト増大と開発の遅延を招き、正確な会計情報がいつまで経っても得られないという致命傷に繋がります。この上、更にシステム会社の売込み攻勢に押されて、J-SOX対応ツールを組込んだ場合は、益々J-SOXの基準からかけ離れていくといった皮肉な事態になり兼ねません。

システムの開発プロジェクトにおいては、（例えば実現させたい機能が５つあったとしても、今回は優先度の高い2つまでという形で）プロジェクトの大きさを会社の身の丈にあわせ、数年に分けて実現させていく、というアプローチを取るべきでしょう。

システムの運用管理者は、開発担当者から明確に分離される必要があります。開発担当者が、自分の作ったプログラムを運用できるようになると、いかようにでもデータ操作が可能となり、不正の温床となるからです。これを職務の分離といいます。

ところで、小規模企業においては、システム部門のスタッフが少ないため、こうした職務の分離が困難である場合があります。この場合は、追加的コントロールによって、プログラムの不正改竄などを防止していくことになります。例えば、開発担当者がシステムの運用管理を兼ねる場合は、プログラム変更時には必ず事前承認を取り、変更履歴のログを残すなどのコントロールを施すことになります。

さて、システムの運用管理におけるIT全般統制が整備されていない場合、財務報告の信頼性にどのような影響が及ぼされるのでしょうか。

• 前期のデータを削除するオペレーションを誤って実行してしまい、当期の売上げデータを削除してしまった結果、当期の売上げの数字が不正確になった。
•  サーバーのダウンに関する予防措置を取っておらず、決算期直前にシステムが稼動せず、財務上の数字を決算
  時までに確定できなかった。

これらに共通する対応としては、データのバックアップということになりますが、災害や重大な障害発生時の復旧計画を策定しておくことは、9.11事件以降、益々重要になってきています。

日本においては地震を想定し、数10ｋｍ以上離れた遠隔地にサーバーを保管しておくことなどを考慮すべきでしょう。

復旧計画の策定に当たっては、目標復旧ポイントと目標復旧時間という概念が重要になります。

【目標復旧ポイントと目標復旧時間】

目標復旧ポイントとは、業務再開にあたり過去のどの時点までのデータを復旧すればいいかを示すポイントです。目標復旧ポイントは短いほど復旧に貢献しますが、リアルタイム性の高い技術を要するため、システム構築費が高くなります。

他方、目標復旧時間とは、中断した業務をいつ再開するかというポイントです。この時間も短ければ短いほど復旧コストはかかりますが、中断による機会損失（売上げの減少、イメージの低下）は時間とともに増大しますので、この2つのコストの合計が最小化するポイントを選択する必要があります。

アクセス管理とセキュリティにおけるIT全般統制が整備されていない場合の、財務報告の信頼性への影響については、想像しやすいと思われます。例えば、次の例が挙げられます。

• 支払いデータベースに悪意のある者がアクセスし、データの改竄を行い、財務報告の信頼性を損なわせてしまった。
•  財務データベースへのアクセス管理が不十分のため、公表前に決算数字が漏れてしまった。
• コンピュータ・ウイルス対策に不備があり、財務データがウィルスに感染し、決算日時を遅延せざるを得なくなった。

こうした事態に対する統制は、

（1）アクセス権限の管理
（2）パスワード
（3）物理的セキュリティの確保
（4）コンピュータ・ウイルス対策
（5）アクセス・ログ

の5つがあります。

まず、（1）アクセス権限の管理とは、個々のユーザー毎に、その人の職務に見合ったシステムへのアクセス権限（例えば、給与データへの閲覧できる権限とか、発注伝票に入力できる権限など）が付与されていることを意味します。

ここで、気をつけるべき点は、（例えば経理部門から営業部門への）人事異動が起きた時に、速やかにアクセス権限の変更ができる仕組みを作ることです。また、退職者のユーザーIDに対する削除についても見落としやすい点ですので注意が必要です。定期的に、ユーザーIDとアクセス権限の付与状況に関するレビューを行うといいでしょう。

次に（2）パスワードについてですが、例えば生年月日のように単純なものを設定させない工夫（最低文字数を増やすなどの措置）や、定期的に変更を義務付けることで、統制がしっかりできます。

ここで、問題にしたいのは、セキュリティ管理者（小規模な会社では運用管理者が兼任する）が、全社員のパスワードを参照可能な状況にしておくという点です。社員がパスワードを忘れた際にすぐに教えられる体制は非常に便利ですが、これではセキュリティ管理者に対する統制が全くないことは明らかです。この場合は、既存のパスワードを初期化し、新しいパスワードを自動生成、もしくは社員が設定する仕組みを組み込むべきです。

（3）物理的セキュリティについては、サーバールームへのアクセスが制限されており、入室履歴が残されていることが求められます。また、上述のシステムの運用管理に関連しますが、システムがダウンしないよう、サーバールームを掃除するとか、消化設備を整えておくことも必要です。

（4）コンピュータ・ウイルス対策は、サーバーと個々のPCにアンチウイルス・ソフトがインストールされていること、そして、企業のコンピュータ・ネットワークに対する外部からの侵入を防ぐファイアーウォールを設けておくということが必要になります。

（5）アクセス・ログについては、「何のログ（履歴）を取るか」について、明確にしておく必要があります。とりあえず、あれもこれもという形で膨大なログをファイルが保管されているが、結局誰もそのログの活用方法を知らなかったという笑い話のような事は結構あります。しかし、これは紛れもなく統制上の不備です。ログの取り方についても、財務報告の信頼性に影響を与える業務機能などに絞っていく、といった見直しが求められます。

アウトソーシングが一般化した現在、業務のアウトソース先（受託会社）の内部統制についても関心を払わねばなりません。実施基準によれば、「経営者は、委託業務に係る内部統制について、当該受託会社が実施している内部統制の整備及び運用状況を把握し、適切に評価しなければならない」としています。

アウトソース先のIT全般統制が整備されていない場合の、財務報告の信頼性への影響については、次のような例を挙げれば十分でしょう。

• ・アウトソース先の給与計算業務システムがダウンしてしまい、今期の人件費計上が遅れてしまった。

さて、アウトソース先の内部統制の評価についえは、2つの方法が考えられます。

1つ目は、アウトソース先から委託業務についての監査報告書を受け取る方法です。日本の監査基準委員会報告書18号であるとか米国のSAS70などに則った監査報告書を受け取っていれば、どの監査法人が作成した報告書でも利用可能です。ただし、この方法はコストが結構かかります。

2つ目は、アウトソース先に、自社の内部監査人と外部監査人が出向くことです。但し、この場合、契約時に「監査を受けること」を契約に盛り込んでおかないと、セキュリティを理由に監査を断られる可能性があります。

では監査を断られた場合はどうするのでしょう？アウトソース先の業務結果を自社で確認するしかなくなりますが、これは結構難易度が高くなるので出来れば避けたいところです。

以上、プロジェクト管理上の注意点を挙げてみました。

以上、6回に渡る連載でしたが、連載タイトルの通り「経営者の視点」に立ち、そもそも論を展開することを心がけました。連載第1回に遡りますが、経営とは事業機会に挑戦する一方で、リスクを統制していくことです。経営者はどうしても前者に力点を置きがちですが、本連載によって、後者の意義、すなわち内部統制の重要性を認識していただければ幸甚です。

その上で、他部署から応援が得られずに疲弊している（中にはやる気をなくし会社を辞めていくというお話も伺います）J-SOXプロジェクト・チームを是非応援してあげてください。内部統制は経営者の責任である以上に、これができるのは経営者しかいないのですから。