IT全般統制の進め方は、連載「日本版SOX法プロジェクトの進め方」（2006年12月～2007年1月）で述べた全体の考え方と基本的に同じである。ここでは、IT全般統制固有のポイントを中心に解説する。
IBM ビジネスコンサルティング サービス
IT全般統制のプロジェクトの進め方は第3章で述べた全体の考え方と基本的に同じですが、ここでは、IT全般統制固有のポイントを中心に解説します。
計画ステージ――IT全般統制の評価範囲
IT全般統制に関する計画ステージの目標は、（1）対象範囲の決定と、（2）文書化・評価単位の把握、（3）現状の統制レベルの把握の三点です。これらが確定することで、後続の文書化や評価に要する、おおよその業務量や実施期間を見積もることが可能になります。
（1）対象範囲の決定
ここでいう対象範囲とは、IT全般統制の対象となるシステム（アプリケーション・システムおよびそれが稼働するインフラ）を指します。これを確定していくためには、基本的に業務プロセス側からアプローチします。財務報告にかかわる業務プロセスを識別し、その業務をサポートするアプリケーション・システムを識別し、それを支えるIT全般統制を識別する流れです。この流れに沿って、IT全般統制の範囲を確定する場合、業務部門での範囲検討を後追いする形になりますが、IT部門はITの検討が始まるまでに、事前準備として、IT環境を棚卸しし、そこからIT全般統制としての文書化・評価の単位を抽出できるようにしておきます（図3）。
 |
| 図3●IT全般統制対象範囲の検討 [画像のクリックで拡大表示] |
（2）文書化・評価単位の把握
IT全般統制は開発や運用の実施方法そのものであり、企業においては必ずしもそれが統一された方法で実施されているとは限りません。一般的には、システムの稼働場所（データセンター）、対応組織、プラットフォーム（ハードウエアやオペレーティング・システム）などが異なる場合、開発・運用の方法、すなわちIT全般統制の統制内容やレベルに差異が発生する例が多いと考えられます。したがってIT環境を棚卸しする際には、これらの要素（場所、組織、プラットフォーム）に着目し情報を整理したうえで、IT全般統制の共通単位＝文書化・評価の単位を抽出します（図4）。
 |
| 図4●文書化・評価単位の抽出 [画像のクリックで拡大表示] |
（3）現状の統制レベルの把握
評価・文書化単位として抽出された単位（例えば、ホスト系とオープン系など）で、現状の統制レベルの概要を把握します。多くの企業では、これまでも継続的にITサービスを提供してきたことから、全くIT全般統制が存在していないというケースはないと考えられますが、場合によっては重大な不備が発見されるかもしれません。不備の内容や取り組むべき対象範囲の大きさによっては、後続のステージでまず不備対応を優先する場合もあり得ます。計画段階で現状の統制レベル（例えば、COBITの一二プロセスに対する成熟度レベル）や潜在的リスクの大きさ（トランザクションのボリューム、システムの数・複雑性、要員の経験・スキル、ITプロセスの複雑性など）について、概要を把握しておくことで、後続のアプローチを計画的に立案することが可能になります。
（4）スプレッドシートに関する考慮点
今日、財務報告にかかわる業務でスプレッドシート（表計算ソフト）を活用する場面が多くなっており、業務の一部として欠かせないツールとなっています。スプレッドシートは手軽に利用できる半面、一般的にはアクセス管理や変更管理などは行われていないのが実情です。スプレッドシートの利用目的や取り扱うデータによっては、財務報告に影響を与える「システム」として、ＩＴ全般統制の適用を検討する必要が生じてきます。ＣＯＢＩＴ ｆｏｒ ＳＯＸは、スプレッドシーの統制に関して、(1)財務報告にかかわるスプレッドシートを棚卸しし、(2)各スプレッドシートのリスクを評価し、(3)リスクに応じて対応策を講じる――という三つのステップからなるアプローチをリスク評価のフレームワークなどとともに紹介しています（図5）。
 |
| 図5●スプレッドシート統制に関するアプローチ例 |
パイロット・導入ステージ――IT全般統制の文書化と評価、不備への対応
（1）IT全般統制の文書化
文書化に関しては、IT環境や組織の規模・複雑性を踏まえ、監査人と協議のうえで決定しますが、一般的にIT全般統制も業務処理統制とほぼ同様の構成の文書が必要と考えられます。
●統制の可視化のために作成する文書
・業務プロセスとアプリケーション・システムとの関連を整理したプロセス・シスム対応表（当資料はIT業務処理統制の補足資料としても必要）
・プロセスごとにリスクとそれを低減するための統制を抽出し、一覧化したリスク・コントロール・マトリクス（RCM）
・当該IT業務プロセスに関する業務の流れを示すフローチャート
・RCMに記載された統制を詳細に記述した業務記述書
●有効性評価のために作成する文書
・統制の有効性を評価するために実施したテストとその結果を記載したテスト記述書
（2）IT全般統制の有効性評価
IT全般統制の有効性は、業務処理統制の有効性に影響を与えます。「全般統制は、情報の信頼性を確保すること、及び業務処理統制の継続的な運用を確実にすることを間接的に支援するものですから、たとえ業務処理統制が有効に機能していたとしても、継続的な運用を保証する全般統制に重要な不備があれば、情報システムの内部統制は有効に機能しないため、統制リスクが高まることになり」（IT 委員会研究報告第三一号）、業務処理統制のテスト範囲やサンプル数に影響を与えます。COBIT ｆｏｒ SOX第二版では、運用テストにおけるサンプル数のガイダンス例を記載していますが、IT全般統制が有効に機能している場合は、一つの統制当たりアプリケーション一つをテストしさえすればよいことになっています。
IT業務を外部委託している場合の考慮点
今日、IT業務に関しては、外部の専門企業を活用して業務の一部あるいは多くを委託（アウトソーシング）しているケースが一般的です。こうした場合でも、最終的に委託業務も含めた自社の内部統制（IT全般統制）に対する責任は委託する側が持つことに注意が必要です。
委託側の企業は、アウトソーサーやベンダーに対して、委託業務にかかわる内部統制を整備・機能させることを要求することになります。この際、委託側からアウトソーサーなどに対して外部監査が可能な契約になっているかが重要なポイントです。また、場合によってはアウトソーサーなどが外部の第三者から一定の基準に基づく監査を受けているケースがあります。
こうしたケースで利用可能な基準として、米国公認会計士協会で定められたSAS七〇（ステートメント・オブ・オーディティング・スタンダード七〇）や、同等の内容を日本公認会計士協会が定めた監査基準委員会報告第一八号「委託業務に係る内部統制の有効性の評価」があります。これらの基準に従ってアウトソーサーなどが外部の監査人によって監査証明を受けている場合、委託側企業は以下の要素を考慮のうえ、その結果を自社の内部統制評価に活用することができます。
・統制のテストがカバーする期間と経営者の評価日との関係。
・報告書の調査範囲とアプリケーション、テストされた統制、テストされた統制と企業の統制との関係。
・統制テストの結果、および統制の運用上の有効性に関するアウトソーサーの監査人の意見。
今後委託者にとっては、委託先を選定する際の新たな選択基準として、内部統制への対応能力の視点を持つことや、委託後も「丸投げ」するのではなく、内部統制が適切に機能していることを継続的にモニタリング、評価していくことが重要になっていくと考えられます。
(3)統制不備への対応
IT全般統制は元来間接的な統制であり、それ自体が直接財務のアサーションに影響を与えるものではありませんが、統制上の不備を放置しておいてもよいわけではありません。PCAOBの二〇〇四年のガイダンスによるとIT全般統制の不備が、重大な欠陥（マテリアル・ウイークネス）とみなされる可能性があるケースとして、以下の三つの例が挙げられています。
・IT全般統制の不備によってアプリケーション統制が無効になる場合。
・ほかの統制不備と一緒になることで、統制環境に影響を与える場合。
・不備を明らかにした後、それが適切な期間内に解消されなかった場合。
IT全般統制の不備がもたらす影響を評価する場合には、これらの観点も踏まえ、IT面だけではなく、業務統制への影響も含めた全体の評価が必要です。
不備への対応を具体的に検討する場合は、システムの重要度や財務報告への影響などを考慮する必要があります。情報システム部門がデータセンターで開発・運用している大規模システムと、ユーザー部門が少人数で開発・運用しているシステムでは対応の方法が異なります。管理者が現実的に置けない場合など、現実を無視してプロセスや標準を整備するわけにはいきません。
プロセスを整備する場合は、同じ「財務報告の信頼性に影響を与えるシステム」でも、規模やリスクなどで、ランク分けを行い、管理のメッシュ（細かさ）を、管理工数との費用対効果で変えます。これを開発標準や運用標準などの「テーラリング」と呼びます。管理の頻度や管理項目の細かさ、承認権限などを、「松竹梅」のケースで作成し、どのケースを採用するかの基準を制定し、各システムで適用の方法を確定させます。
実際の適用の中では、様々な例外ケースもあります。例えば、重要なシステムで厳密な管理（「松」の管理）をしたいが、実体は表計算ソフトで、開発も運用も一人で実施しているといったケースもあり得ます。重要なシステムの場合は、一般的に開発者と運用者を分ける、いわゆる職務の分離で変更管理にかかわる内部統制を確立します。しかし現実解として、それが実現できないようなケースでは、その変更管理で、どこにリスクがあるかを十分に吟味し、補完的な統制を整備するようにします。この例では、財務報告にかかわるような表計算ソフトを変更した場合、変更台帳に変更内容を記述し、仕様書などを変更したうえで、「変更した内容や出力結果、手作業で実施した結果との突き合わせなどを、別の管理者に見てもらい確認してもらう」といった統制が考えられます。
運用ステージ――IT全般統制の継続的な改善と自動化
内部統制は一過性のものではなく、長期にわたって継続的に定着させていくことが基本です。統制のレベルを維持・向上し、かつ定期的に実施するテストの効率性を高めていくには、統制の自動化が大きなポイントになります。これは業務処理統制においても共通にいえることですが、IT全般統制においても、業務の中で自動化できる余地は多く残されています。特に多数のテストが必要な大規模な組織では、開発や運用プロセスの自動化によって、長期的な視点で内部統制の維持にかかるコストの最適化が可能と考えられます。例えば、プラットフォームやシステム単位にばらばらに人手で行っていたシステム管理プロセスを統合し、自動化することで、テストの回数、サンプル数ともに激減させることが可能です。
SOX法以前には、あまり議論されてきませんでしたが、企業は今後コンプライアンスにかかるコストの最適化を考えていく必要があります。次節ではIT全般統制の運用段階で、さらに統制の品質や効率性を追及するアプローチについて述べます。
|
出典：「プロジェクト現場から見た内部統制～実務者が語る日本版SOX法対策」（IBM ビジネスコンサルティング サービス著，日経情報ストラテジー編集，日経BP社刊）より（詳細情報はこちら）
