米SOX法対応を実施するIT関係者は、IT統制を確立・評価する際の指針として「COBIT for SOX」を参考にすることが多い。今年4月に草案が公開された第2版では、日本版SOX法への対応を急ぐシステム部門に役立つ追加・改変がなされている。第2版の公開草案を基に、その実際を紹介する。

公認会計士 深見 浩一郎

 企業におけるITガバナンスの確立を目指した包括的なフレームワーク(評価基準の体系)であるCOBITの存在は、よく知られている。COBIT for SOX(IT Control Objectives for Sarbanes-Oxley)は、COBITの内容を「財務報告にかかる内部統制」の視点で抽出・整理し、米SOX法対応で必要とされるIT統制の目標を明確にしたものである。

 第1版は2003年に公表され、今年4月に第2版(2nd Edition)の草案が公開された。8月現在でまだ確定版は公表されていないが、日本版SOX法と同様の「トップダウン・リスクアプローチ」に関するガイダンスを中心に、「表計算ソフトの扱い方」、「米SOX法対応企業の経験」を示すなど、日本企業のシステム部門に役立ちそうな数々の改訂が盛り込まれている(表1)。以下、この公開草案を基にCOBIT for SOX第2版の内容を説明していく。

表1●「COBIT for SOX 第2版」の主な改訂のポイント
表1●「COBIT for SOX 第2版」の主な改訂のポイント
[画像のクリックで拡大表示]

画一型からトップダウン型に改訂

 米国では現在、内部統制監査を規定した「米SOX法404条」を改革する方向で議論が進んでいる。注目点は、404条の制度運用方針としてトップダウン・リスクアプローチの適用を明確に打ち出したことだ。まず、この点について簡単に確認しておこう。

 これまでの米SOX法対策で、極めて評判の悪いものに「標準チェックリスト方式」がある。企業の規模や業種・業態などにかかわらず、画一的なチェックリストを使って統制(コントロール)の整備を進める、というやり方である。この手法は、整備を推進する担当者のスキルによらず、一定水準の成果が期待できる半面、内部統制の構築費用の高騰という事態を招いた。画一的なアプローチによって、統制を過剰に整備してしまったり、逆に統制の不足が見つかり、それに対する追加整備が生じたりしたからである。

 これに対し、トップダウン・リスクアプローチでは、経営者自らが「事業運営上、どのリスクを重視するか」を判断し、そのリスクに応じた内部統制の整備を試みる。SOX法におけるリスクは「財務諸表における虚偽記載」を意味する。つまりSOX法対応に際し、この手法では、財務報告の信頼性に影響を及ぼすリスクを経営者自身が明らかにして、そのリスクの重要性に応じた水準の統制を整備していく。標準チェックリスト方式に比べ、このような合理性を持つことから、構築費用の抑制効果が期待されている。

 COBIT for SOXが対象とするIT統制についても、トップダウン・リスクアプローチが適用される。財務報告プロセスにおけるITリスクを判断し、それに対応したIT統制の整備を経営者のリスク評価方針に基づいて行うことになる。COBIT for SOXの改訂は、この動きを踏まえたものだ。以下、第2版にその具体的内容をみていこう。

(1)ITの棚卸

 IT統制の整備は、自社の情報システムの現状把握、すなわち“ITの棚卸”から始まる。対象は、財務報告プロセスにかかわるアプリケーションと、それに関連するサブシステムである。

 棚卸の際は、該当するシステムの特定だけでなく、関連する業務プロセス、パッケージか自社開発か、カスタマイズの有無などといった特徴のほか、データベースやOS、ハードウエア、設置施設についても調べる(表2)。

表2●財務報告の作成に関連するアプリケーションやサブシステムの「棚卸」の例
表2●財務報告の作成に関連するアプリケーションやサブシステムの「棚卸」の例
[画像のクリックで拡大表示]

 ITの棚卸では、財務プロセスとの関連を常に考慮しなければならない。ERPパッケージ(統合業務パッケージ)を利用した複雑なアプリケーション・システムだけでなく、簡易な計算プログラムも該当する点に注意が必要だ。例えば、時間外給与の根拠になる残業時間を算出する「出退勤管理システム」は、対象となる可能性が高い。人件費という重要な勘定科目に関連するためである。Excelなどの表計算ソフトを使って構築したプロジェクト管理システムも、そのデータが期末仕掛品の算定根拠になっているケースでは、対象となる(表計算ソフトについては後述)。

 ITの棚卸の結果は、ITリスクの評価だけでなく、IT統制の評価やテストを実施する際の資料にもなる。日本版SOX法への対応においても実施すべき項目の一つと言える。

(2)ITリスク評価

 lTの棚卸の結果に基づき、ITリスク評価を実施する。これは、財務報告との関連を踏まえた上で、情報システムにどのようなリスクが存在し、そのリスクがどの程度の大きさかを把握することを指す。

 第2版は、ITリスクを評価する場合に考慮すべき事項を示している。例えば「技術的要素」に関して、独自に開発したアプリケーションを使っているなら「リスク大」、パッケージを使っているなら「リスク小」、「人的要素」に関して、経験が少ないなら「リスク大」、経験豊富なら「リスク小」などと例を挙げている(表3)。

表3●リスク評価の際に考慮すべきリスク要素の例
表3●リスク評価の際に考慮すべきリスク要素の例
[画像のクリックで拡大表示]

 加えて、アプリケーションやデータベース、OS、ハードウエア、ネットワーク、設置場所のそれぞれについて、技術的要素や人的要素などに関してリスクの大小を評価する。

(3)整備とキー・コントロール

 ITリスク評価により特定されたITリスクのうち、「重大」なものに対応する統制を「キー・コントロール」と呼ぶ。トップダウン・リスクアプローチでIT統制を有効に機能させるためには、キー・コントロールを的確に整備・運用することが欠かせない。ちなみに日本版SOX法の基準案では、キー・コントロールを「統制上の要点」と呼んでいる。

 第2版では、COBITによる「変更管理」、「委託先管理」、「セキュリティ」など12の分野についてIT統制目標を示し、さらに財務報告との関連において、どれがキー・コントロールとなるかを例示している。例えば「変更管理」に関連する四つの統制のうち、「プログラム変更、システム変更および保守管理の要求は標準化され、文書化された正式な変更管理手続きに従う」など三つをキー・コントロールとしている(COBIT for SOX第2版では、カギ型のアイコンで示している)。これらは、IT全般統制に関する参考資料で説明されている。

 第2版でキー・コントロールを例示しているものの、現時点で公的な定義は存在しない。そこで第2版では、統制がキー・コントロールかどうかを識別する際に考慮すべき項目として、以下の5点を挙げる。
a) 重大なリスクへの方針や手続き、実施手順、組織体制などを含んでいるか:キー・コントロールには、重大なリスクに対応するためのシステマチックな仕組みが必要とされる(例えば、セキュリティ・ポリシー)
b) 複数の統制目標に対応しているか:例えば財務情報の信頼性を保証し、職務分掌の整備にもつながるアクセス統制はキー・コントロールである
c) 重大なリスクに直接対応しているか:企業にとって基幹システムへの「不正アクセス」は重大なリスクにつながりかねないことから、これに関連するセキュリティ統制はキー・コントロールである
d) リスクの発生を未然に防ぐ「予防的統制」か:重大なリスクに対応しているキー・コントロールでは、事が起こってからの事後的な対応では致命的な場合がある
e) 自動化された統制か:プログラムによって自動化された統制には首尾一貫性があり、人による統制行為に比べ信頼性が高い