4.4IT統制（IT全般統制とIT業務処理統制）

ITシステムの統制は、大きく2つの層に分けて評価します。1つは、システムが動く基盤そのものを守るIT全般統制（ITGC）——誰がシステムを変更・アクセスできるか、変更が正しく管理されているか、運用が安定しているか。もう1つは、その基盤の上で動く個々の業務処理の正しさを守るIT業務処理統制——入力データが正確か、処理が網羅的か、出力が正当か。監査人にとって決定的に重要なのは、この2層には依存関係があり、ITGCが有効でないとIT業務処理統制もそのままでは信頼できないという点です。この節では、両者の役割の違いと依存関係を踏まえ、統制不備がどう波及するかを診断する視点を養います。

4.4.1IT全般統制（ITGC）

• IT全般統制（ITGC：IT General Controls）＝個々の業務処理統制が有効に機能するための前提となる基盤統制。代表的な領域は(1)アクセス管理（誰が何にアクセス・操作できるかの権限管理・認証）、(2)プログラム変更管理（本番プログラムの変更が承認・テスト・移行の手続を経ること）、(3)システムの開発・導入（要件・テスト・移行の統制）、(4)運用管理（ジョブ実行・バックアップ・障害対応・構成管理）の4つ。
• ITGCの各領域には職務分掌が深く関わる。例えば開発者が本番環境へ直接プログラムをリリースできる体制は、テストされていない変更や不正な変更が混入する予防統制の欠如であり、ITGCの弱点となる。監査人は「開発と本番移行の権限が分離されているか」「変更に承認記録があるか」などを整備・運用の両面から評価する。

4.4.2IT業務処理統制

• IT業務処理統制（IT application control）＝個々の業務アプリケーションの中で、処理される取引データの正確性・網羅性・正当性・維持継続性を確保する統制。入力統制（チェックディジット・入力値の妥当性チェック・必須項目チェック等）、処理統制（バッチコントロール＝件数・合計金額の照合、二重処理防止）、出力統制（出力先の限定・出力結果の照合）に分かれる。
• IT業務処理統制は「その業務でどんな誤りやなりすましが起きうるか」に対応して設計される。例えば受注入力なら、数量に負の値を入れられないバリデーション（入力統制）、登録件数と処理件数が一致するかの照合（処理統制）、請求書の出力が承認済み取引に限られる制御（出力統制）などが該当する。

あるシステム監査人が、受注システムのIT統制を評価しているとします。アプリケーションを調べると、業務処理統制はよく設計されていました——受注入力には妥当性チェック（負の数量を弾く入力統制）があり、日次の受注件数と会計連携件数を突合するバッチコントロール（処理統制）も動いています。監査人はここで「業務処理統制が有効だから、この受注データは信頼できる」と結論づけたくなります。しかしIT全般統制を確認すると、重大な問題が見つかりました——開発者が本番プログラムを承認・テストなしに直接書き換えられる権限を持っており、変更管理の記録も残っていないのです。ここで監査人が下すべき判断が、この節の核心です。IT業務処理統制がどれほど精緻に設計されていても、その統制ロジック自体を実装しているプログラムを、誰かが承認もテストもなく書き換えられるなら、業務処理統制が本当に設計どおり動作している保証はない。極端に言えば、負の数量を弾くチェックを開発者がこっそり無効化しても、変更管理の記録が無いため誰も気づけません。つまりITGC（プログラム変更管理・アクセス管理）が有効でないと、その上で動くIT業務処理統制の信頼性そのものが崩れるのです。したがって監査人は、業務処理統制が表面上有効に見えても、ITGCの不備を根本原因として、業務処理統制への依拠を制限し、より広範な実証手続（試査範囲の拡大やデータの直接検証）が必要と判断します。ここでのひっかけは、アプリ内の統制（入力/処理/出力）だけを見て「よくできているから安心」と評価を終えてしまうことです——IT統制の評価は必ず基盤（ITGC）から積み上げ、ITGCが弱ければ業務処理統制への信頼度を割り引くのが監査の原則です。

4.4.3この節のまとめ

• IT全般統制（ITGC）＝アクセス管理・プログラム変更管理・開発導入・運用管理の基盤統制（業務処理統制の前提）
• IT業務処理統制＝入力/処理/出力の正確性・網羅性・正当性を守る統制（チェックディジット・バッチコントロール等）
• ★ITGCが有効でないとIT業務処理統制も信頼できない——監査人は基盤から積み上げ、ITGCが弱ければ業務処理統制への依拠を割り引く