IT一般統制（IT General Controls）

ポイント

> - ITGCが機能していなければ、個別のアプリケーション統制をテストしても信頼できない。基盤が崩れていれば、上層部の検証は無意味である。 > - アクセス管理、変更管理、バックアップと復旧、システム操作ログの4領域が柱となる。いずれかが欠けると、ITシステム全体のリスク評価が「高」に跳ね上がる。 > - CPAAOBの検査で最も多い指摘は、開発環境と本番環境の分離不十分。中堅企業ではこれが見落とされやすい。

---

仕組み

ITGCはITシステムの信頼性を支える土台にあたる。監基報315第34項は、監査人に対し、被監査会社のITシステムが会計データをどのように処理するかを理解するよう求めている。これを理解しなければ、財務報告に関する虚偽表示リスクを評価できない。

具体的には、以下の4つの領域で統制が機能しているかを確認する。

アクセス管理（Access Controls） — システムに誰がアクセスでき、何ができるかを制限する統制。給与台帳システムに経理以外の者がアクセスできたら、改ざんリスクが発生する。ISA 315.A73は、権限付与と権限取り消しのプロセスが文書化されていることを前提としている。

変更管理（Change Management） — システムやデータベースへの変更が、許可を得た上で適切に記録される統制。本番環境のコード変更が未承認で行われていれば、財務計算ロジックが意図せず変わってしまう可能性がある。ISA 315.A75では、開発環境と本番環境の分離が強調されている。

バックアップと復旧（Backup and Recovery） — データが失われた場合に復旧できる仕組み。月次決算処理の途中でシステムがダウンし、バックアップから復旧する際、復旧後のデータが正確であることを確認する統制が必要となる。

システム操作ログ（System Logs and Monitoring） — 誰が、いつ、何をしたかが記録され、異常なアクティビティが検知される仕組み。売上計上システムで深夜に大量の取引が入力された場合、それが許可された作業かどうかを追跡できなければならない。

これら4領域の統制が全て機能していることが、自動化された統制（例：システムが自動計算する売上高控除額）の信頼性の前提条件となる。

---

実務例：テクレア・ジャパン株式会社

被監査会社: 日本の中堅製造業、FY2024、売上9億2,000万円、IFRS報告

テクレア・ジャパンは受注生産型の製造企業で、ERPシステムで受注から請求までのプロセスを自動化している。監査の過程で、このERP上で自動計算される売上高が、ISA 330.A74で求めるITGCの下で正確に処理されているかを確認する必要がある。

ステップ1：アクセス管理の確認 ERPのアクセス権限リストを入手し、売上計上権限を持つユーザーを特定する。結果、営業部員16名が売上入力権限を持ち、その他の職員はリード・オンリー権限に限定されていた。

調書ノート：IT統制テスト作業簡紙「アクセス権限設定」欄に「ERP権限管理レポート_2024年10月」を参照として記載。16名のユーザーID、各自の権限レベル、付与日を確認。

ステップ2：変更管理プロセスの確認 ERPの売上計上ロジックに変更があったかを確認。本年度、新しい軽減税率対応ロジックが4月に導入されていた。この変更が変更管理ポリシーに従ってテストされ、承認されたかを検証する。変更前後のテストケースと、品管部門による承認エビデンスが存在することを確認。

調書ノート：「システム変更ログ」に、変更ID、変更日時、変更内容（軽減税率ロジック追加）、テスト完了日、承認者（情報システム部長）を記載。品管部の承認メール添付。

ステップ3：開発環境と本番環境の分離確認 IT管理者に対して、開発・ステージング・本番環境が物理的および論理的に分離されているかを確認。本社ネットワーク図、アクセス権限、バックアップスケジュールを検証する。開発者が本番環境へのアクセスを持たないことを確認。

調書ノート：IT管理者への質問事項「開発者の本番環境アクセス権限」に対し、「本番環境へのアクセスは禁止。変更は変更管理プロセスを経由してのみ適用」との回答を記録。ネットワーク図で3つの環境が分離されていることを視認。

ステップ4：バックアップと復旧テスト 直近のバックアップが実際に復旧可能か、復旧後のデータが正確かを確認する。月次決算処理の前日に行われるフルバックアップが、実際に復旧でき、復旧後の売上台帳データが本番環境と一致することを検証。

調書ノート：バックアップ復旧テスト結果に、バックアップ実施日、復旧実施日、復旧後のデータ件数（売上伝票12,847件）が本番環境と一致することを記載。復旧完了時刻と確認者を署名。

結論 4つのITGC領域全てが機能していることが確認された。ERP上で自動計算される売上高（実装統制として分類）に対するテストの有効性が支持される。この確認がなければ、自動計算結果の正確性を直接テストせざるを得なくなり、監査効率は大きく低下する。

---

監査人と検査機関が見落としやすい点

Tier 1：検査指摘に基づく実際の誤り

CPAAOBの検査報告書では、中規模企業の監査で以下の指摘が繰り返されている。開発環境と本番環境が十分に分離されていないために、開発者がテスト目的で本番売上データベースへのアクセスを保有していたケース。テストデータが誤って本番環境に残り、決算データが汚染されるリスクが生じた。これはITGCの「変更管理」領域の不備と「アクセス管理」領域の不備の複合的な結果である。

Tier 2：標準が要求する実装ポイント

監基報315第34項に準拠するためには、単にIT統制が「存在すること」ではなく「機能していること」を監査人が検証する必要がある。存在するが運用されていないアクセス管理ポリシーは統制とは言えない。正直、権限付与から90日以内に実装されなかったアクセス権が放置されている例は非常に多い。ISA 315.A73で「定期的なレビュー」が求められているのはこのためだが、年1回の棚卸しだけで済ませるチームが大多数にすぎない。

Tier 3：実装上の課題

ITGCの調書がITチームだけに留まり、監査チームが検証しにくい技術資料（ネットワークダイアグラム、コンフィグ設定ファイル）で提供されるケースは珍しくない。監査人はこの技術資料を監査証拠として使おうとするが、その信頼性をどう検証するかについて明確なガイダンスを持たない。クラウドベースのシステムが増えるにつれ、クラウドプロバイダーのSOC 2レポートに過度に依存する傾向も出ている。プロバイダーの統制が強固でも、企業自身のアクセス管理（誰がプロバイダーダッシュボードにアクセスするか）が甘ければ、リスクは顕在化する。

---

IT一般統制 vs. IT応用統制

自動化された統制（例：システムが自動計算する売上控除額）とITGCの関係は明確に区別される。

ITGCはITシステム全体の信頼性を支える基礎である。IT応用統制（Application Controls）は、特定の業務プロセス（売上計上、在庫計算、給与計算、固定資産管理）の中で、特定の目的（売上の正確性、在庫金額の適切性）を達成するための統制にあたる。

ITGCが機能していなければ、個別のIT応用統制をいくら手厚くテストしても、その結果を信頼することはできない。変更管理が機能していなければ、売上計上ロジックがいつどのように変わったかが追跡できず、計算結果の信頼性に疑問が生じるだろう。

ISA 330.A74はこの関係性を明示している。監査人はITGCを評価した後、その評価結果に基づいてIT応用統制のテスト範囲・深さを決定する。ITGCが「低リスク」なら応用統制のテストを効率化できる。「高リスク」なら、応用統制の直接的なテスト（例：売上計上ロジックのホワイトボックステスト）が必要になる。

---

関連用語

- IT応用統制: 売上計上、給与計算など、特定の業務プロセスの正確性を確保するための統制。一般統制が基礎、応用統制が構造。

- 内部統制の評価: ISA 315全体の枠組み。ITGCはこの中の1つのコンポーネント。

- システムリスク: ITシステムの不備や障害が起因となる監査上のリスク。ITGCが弱いとシステムリスクが高まる。

- 自動化された統制: システムが自動実行する統制。その信頼性はITGCに依存。

- 情報セキュリティと監査: セキュリティ統制とITGCの交差領域。アクセス管理はその典型例。

- クラウドシステムの監査: オンプレミスと異なるITGC検証方法。SOC 2レポートの活用と限界。

---

関連ツール

テクレア・ジャパンの例で使用したアクセス管理テストおよび変更管理テストについては、IT一般統制評価チェックリストで段階的なテスト手順が提供されている。

---