内部統制実務講座

13

� �

財務報告に係る内部統制評価の実務

ーITに係る全般統制ー

公認会計士　鈴木淳二

1. はじめに

「内部統制実務講座 」の第4回（ Vol.20）で

「 IT統制にかかわる実務上の注意点 」を掲載し

ました。その後、「財務報告に係る内部統制の

評価及び監査に関する実施基準 」（以下、実施

基準）が公表されましたが、その中でIT統制は

「 ITに係る全般統制」と「 ITに係る業務処理統

制」とに二分割されています。

本稿では、ITに係る全般統制（以下、IT全般

統制）に焦点を当てます。

2. IT全般統制の難しさ

IT全般統制は、従来の財務諸表監査の中で

も、欧米系企業の監査においては数十年前から

監査対象となっていました。それだけの蓄積が

ありながら、サーベインズ・オックスレイ法（ SOX

法）404条対応の中でも相当、混乱が見られたと

いうところに、IT全般統制の難しさが表れてい

ます。要するに、

① もともと、分かりにくい

② ゆえに、非常に誤解も多い

③ それだけに、評価実務も難しい

④ 以上のような状況の中で、的確に整備と運用

をしていくことが求められる

といった厄介な領域なのです。

上記の中でも①～③は、いわば「プロジェク

ト管理上のリスク」（④を達成できないリスク）

であるともいえます。よって、これらのリスクを

最小化するための実務進行上のアプローチは

何か、という観点から本稿を構成します。

3. 本質の理解を　 何よりも重視しましょう

以下、比較的、概念的な話が中心になります。

今の時期、もっと具体的な手順の話を聞きた

い、とお思いのことでしょう。しかし、ちょっと

待ってください。本質を理解せずに「手順 」か

ら入ってしまうと、「何をどこまでやればいいの

か」を見失い、壮大な無駄が生じる恐れがあり

ます。

本質を理解するというのは、この場合、目的を

明確にし、その目的達成上の「リスク」を常に意

識することです。これが「リスクベース」あるい

は「リスクアプローチ」と表現されているところ

の考え方です。

4. リスクとは何か？

皆さんは「 ITのリスク」という言葉から、何を

想像しますか。個人情報の漏ろう

洩えい

と悪用、ハッカー

やなりすまし、技術の急激な進歩とそれに伴う

旧技術・旧製品の陳腐化など、多岐にわたると

思います（＜表1＞参照）。

では、上記のような「 ITのリスク」は、財務報

告にどの程度、影響するのでしょうか。もちろ

ん、これらの事故などが起きれば、顧客や社会

の信用を失い、企業の存亡にかかわるダメージ

を受けるかもしれません。しかし、それは「財務

報告に係るリスク」でしょうか。

ITは、その利用範囲があまりに広いために、

何についてでも「影響しないとは言い切れな

い」ものです。よって、ここで重要なのは、そ

れを「財務報告に係るリスク」とし、現実に対

処すべきものとして取り上げるかどうかの「判

断」です。

内部統制には限界があるので、費用対効果に

照らした経営判断によって取捨選択するもので

あるということは、今ではよく知られていると思

います。

内部統制は、組織の経営判断において、費

用と便益との比較衡量の下で整備及び運

用される。

（実施基準 I．3）

5. IT全般統制がもたらす「便益」

上記引用でいう「比較衡量 」をするために、

IT全般統制を評価・監査対象として「有効」と

されたことによって得られる「便益 」が何である

かを考えてみましょう。それは「システムが安定

稼働している」といった総合的なものではなく、

次のように、もっと具体的なものです。

「財務報告に係る内部統制 」は、ある一定期

間にわたって、それが有効だったといえるため

のサンプルテストを、統制ごとに複数件（25件な

ど）ずつ行うわけですが、 ● その統制が「自動化（システム化）」されている

場合には、それを25件などのテスト対象とする

ことの合理性に疑問がある ● まず、期中で1件テストを行った上で、そのシス

テムが「変わっていない、あるいは、きちんと

チェックをされた上で変わった」ことを検証し

たほうが、合理的ではないか

と考える人は多いはずです。その考え方を実現

するのがIT全般統制なのです。

このことは、実施基準からも読み取れます。

また、ITを利用した内部統制は一貫した処

理を反復継続するため、その整備状況が有

効であると評価された場合には、ITに係る

全般統制の有効性を前提に、人手による内

部統制よりも、例えばサンプル数を減らし、

サンプルの対象期間を短くするなど、一般

に運用状況の評価作業を減らすことがで

きる。

（実施基準 II. 3 （3） ④ ニ. a）

6. IT全般統制と　業務処理統制の関係

IT全般統制を評価・監査対象とし、「有効」と

なった場合に、その「便益 」が前記のようなもの

であるとしたら、IT全般統制は常に「どの業務

処理統制の『反復継続 』を支えているのか」を

目的の例 リスクの例 内部統制の例

機密保護• 個人情報が漏洩してしまう。• 企業機密が漏洩してしまう。

• アクセス制限• メディア使用制限• 外部接続の制限

可用性維持 • システムダウンにより業務が滞る。• 処理能力モニタリング• ウイルス対策• ハード障害や災害の対策

財務報告の正確性維持• プログラムの改ざん• テスト不足のままの本番稼働

• 本稼働前のテスト結果承認の 網羅性と第三者性の確保

■表1

内部統制実務講座

13

財務報告に係る内部統制評価の実務

10 11

明確にした上で認識されているべきです。なぜ

なら、それが明確でなければ、● IT全般統制に不備が出た場合の影響判断や

代替的手続きの選択ができない● それ以前に、そのIT全般統制を評価・監査の

対象（ひいては、それ以前の整備・運用の対

象）にするかという（費用対効果に関する）経

営判断ができない

ということになるはずだからです。

そもそも実施基準においてIT全般統制は、業

務処理統制との関係において定義されていま

す。このことが、両者の関係の重要性を示して

いるといえます。

ITに係る全般統制とは、業務処理統制が

有効に機能する環境を保証するための統

制活動を意味しており、通常、複数の業務

処理統制に関係する方針と手続をいう。

（実施基準 I. 2 （6） ②［ ITの統制］ロ. a）

IT全般統制の評価対象は、「重要勘定→業

務プロセス（取引フロー）→業務処理統制（の中

の自動化された統制活動）→IT基盤→IT全般

統制プロセス種類 」という「つながり」によって

特定されます（＜図1＞参照）。

ここで重要なことは、この「つながり」の重要

な中継点たる「業務処理統制 」は、そのすべて

ではなく、運用テスト（＝期間にわたる有効性の

検証）の対象となるもの、つまり「キーコントロー

ル」に限られるということです。

なぜなら、「6． IT全般統制と業務処理統制の

関係」の冒頭で記したように、IT全般統制の存

在意義は、業務処理統制の「反復継続 」を支え

るものだからです。「反復継続 」の検証対象で

はない（＝運用テスト対象ではない）統制に対し

ては、IT全般統制はあまり意味がないというこ

とはお分かりかと思います。

② 業務プロセス

Ａ Ｂ Ｃ Ｄ

①重要勘定

１

２

３

４

５ ⑤ 基盤

Ａ Ｂ Ｃ

④アプリケーション

１ ○ ○ ○

２ ○ ○

３ ○ ○

４ ○ ○

③業務処理統制（の中の自動化された統制活動）された統制活動）

⑥ IT全般統制

プロセスα１ ○ ○

２ ○

プロセスβ

１ ○

２ ○

３ ○

プロセスγ１ ○

２ ○ ○

ＩＴ全般統制の評価の結論の出方

プロセスαは1（基盤AとBに共通）と2（基盤C単独）の二つの異なる内部統制プロセスに分けて評価し、別々に結論が出る。プロセスαの1の結論の影響は、基盤AとBで稼働するアプリケーション1～3の三つに及び、同アプリケーションがキーコントロールを提供する業務プロセスA～Cに及ぶ。プロセスαの 2の結論は、基盤Cに影響するのみで、この基盤はアプリケーション４そして業務プロセスDに影響するのみである。

■図 1

7. 「便益」に対する「費用」まで　 考慮する場合

ここで、＜図1＞で示したような「つながり」を

持つシステムの中でも、運用テスト対象になるも

の（キーコントロール）である業務処理統制を多

数提供しているシステム（の基盤）でないと、IT

全般統制の評価・監査は割に合わない場合も多

いということを強調しておきます。ここが本稿

で一番重要なところです。

一つのIT基盤に関するIT全般統制の評価に

は、相当な工数がかかります。＜図1＞では「プ

ロセスα」「プロセスβ」といった表現がされて

いますが、これが実施基準でいう「開発・保守」

「運用」「アクセス権 」などに相当します。これ

らの中でさらに、さまざまな統制につき、さまざ

まなデザインやテスト手続きが要求されます。

一概にはいえませんが、IT基盤一つ当たり10～

20人日程度は必要ではないでしょうか。

一方で、そのIT全般統制が支える業務側キー

コントロールが一つや二つであれば、キーコント

ロールを直接25件テストする作業が1日で十分な

ケースも考えられます。この場合、どちらが合理

的かは明白だと思います。

8. IT全般統制が　最も効率的である場合

結局、IT全般統制（への依存）の費用対効果

が最も高い状況とは、● 基幹業務が上流（各業務）から下流（会計）ま

で一つのシステムに統合されている● それを国内拠点（子会社を含む）の大半で

使っていることはもちろん、多くの海外拠点で

も使っている● つまり、そのシステム一つが、業務側キーコン

トロールを数十個以上、提供している

というような状況であるということができます。

欧米企業（しかも、SOX法404条の対象と

なっているような大規模企業）によく見られる状

況です。しかし、それを日本企業、しかも大規模

企業以外にそのまま適用することには無理があ

るかもしれません。システム個別で費用対効果

を吟味すると、IT全般統制を評価・監査の対象

とするメリットのあるシステムは皆無という日本

企業も珍しくないかもしれないのです。だから

といって、システムを一つもその評価対象にしな

いとなると、今度は「全社的な内部統制 」上、問

題ありということにもなりかねません。

厄介な論点なのですが、当法人では、あくまで

「リスクベース」で考えた妥当な力配分を提案で

きるよう、理論構築を進めています。

9. おわりに

以上、IT全般統制に関する最も重要なテーマ

を取り扱いました。これらが、「2. IT全般統制

の難しさ」で①～③として挙げた「プロジェクト

管理上のリスク」、つまり④（的確な整備・運用）

という目的が達成できないリスクに対処するた

めに理解が必要な内容です。

①→②

⑤→⑥

②→③

④→⑤