重要なポイント
IT一般統制が機能していなければ、個別のアプリケーション統制をテストしても信頼できない。基盤が崩れていれば、上層部の検証は無意味。
アクセス管理、変更管理、バックアップと復旧が3本柱。これらのいずれかが欠けると、ITシステム全体のリスク評価が「高」に跳ね上がる。
最も一般的な検査指摘は、開発環境と本番環境の分離不十分。中堅企業ではこれが見落とされやすい。
仕組み
IT一般統制とは、ITシステムの信頼性を支える土台である。ISA 315.34は、監査人に対し、被監査会社のITシステムが重要な会計データをどのように処理するかを理解するよう求めている。これを理解しなければ、財務報告に関する実質的な誤謬リスクを評価できない。
具体的には、以下の4つの領域で統制が機能しているかを確認する必要がある。
アクセス管理（Access Controls）: システムに誰がアクセスでき、何ができるかを制限する統制。給与台帳システムに経理以外の者がアクセスできたら、改ざんリスクが発生する。ISA 315.A73は、権限付与と権限取り消しのプロセスが文書化されていることを前提としている。
変更管理（Change Management）: システムやデータベースへの変更が、許可を得た上で、適切に記録される統制。本番環境のコード変更が未承認で行われていれば、財務計算ロジックが意図せず変わってしまう可能性がある。ISA 315.A75では、開発環境と本番環境の分離が強調されている。
バックアップと復旧（Backup and Recovery）: データが失われた場合に復旧できる仕組み。月次決算処理の途中でシステムがダウンして、バックアップから復旧する際、復旧後のデータが正確であることを確認する統制が必要。
システム操作ログ（System Logs and Monitoring）: 誰が、いつ、何をしたかが記録され、異常なアクティビティが検知される仕組み。売上計上システムで深夜に大量の取引が入力された場合、それが許可された作業かどうかを追跡できることが重要。
これらの統制が全て機能していることが、自動化された統制（例：システムが自動計算する売上高控除額）の信頼性の前提条件となる。
実務例：テクレア・ジャパン株式会社
被監査会社: 日本の中堅製造業、FY2024、売上9億2,000万円、IFRS報告
テクレア・ジャパンは受注生産型の製造企業で、ERPシステムで受注から請求までのプロセスを自動化している。監査の過程で、このERP上で自動計算される売上高が、ISA 330.A74で求めるIT一般統制の下で正確に処理されているかを確認する必要がある。
ステップ1：アクセス管理の確認
ERPのアクセス権限リストを入手し、売上計上権限を持つユーザーを特定する。結果、営業部員16名が売上入力権限を持ち、その他の職員はリード・オンリー権限に限定されていることが確認された。
文書化ノート：IT統制テスト作業簡紙「アクセス権限設定」欄に「ERP権限管理レポート_2024年10月」を参照として記載。16名のユーザーID、各自の権限レベル、付与日を確認。
ステップ2：変更管理プロセスの確認
ERPの売上計上ロジックに変更があったかを確認。本年度、新しい軽減税率対応ロジックが4月に導入されたことが判明した。この変更が、変更管理ポリシーに従って、テストされ、承認されたかを検証する。変更前後のテストケースと、品質保証部による承認エビデンスが存在することを確認。
文書化ノート：「システム変更ログ」に、変更ID、変更日時、変更内容（軽減税率ロジック追加）、テスト完了日、承認者（情報システム部長）を記載。QA部の承認メール添付。
ステップ3：開発環境と本番環境の分離確認
IT管理者に対して、開発・ステージング・本番環境が物理的および論理的に分離されているかを確認。本社ネットワーク図、アクセス権限、バックアップスケジュールを検証する。開発者が本番環境へのアクセスを持たないことを確認。
文書化ノート：IT管理者への質問事項「開発者の本番環境アクセス権限」に対し、「本番環境へのアクセスは禁止。変更は変更管理プロセスを経由してのみ適用」との回答を記録。ネットワーク図で3つの環境が分離されていることを視認。
ステップ4：バックアップと復旧テスト
直近のバックアップが実際に復旧可能か、復旧後のデータが正確かを確認する。月次決算処理の前日に行われるフルバックアップが、実際に復旧でき、復旧後の売上台帳データが本番環境と一致することを検証。
文書化ノート：バックアップ復旧テスト結果に、バックアップ実施日、復旧実施日、復旧後のデータ件数（売上伝票12,847件）が本番環境と一致することを記載。復旧完了時刻と確認者を署名。
結論
4つのIT一般統制領域全てが機能していることが確認された。したがって、ERP上で自動計算される売上高（基本的に実装統制として分類）に対するテストの有効性が支持される。この確認がなければ、自動計算結果の正確性を直接テストせざるを得なくなり、監査効率が大きく低下する。
監査人と検査機関が見落としやすい点
Tier 1：検査指摘に基づく実際の誤り
FRCの2023年度のモニタリングレポートでは、中規模企業の監査で以下が指摘されている：開発環境と本番環境が十分に分離されていないために、開発者がテスト目的で本番売上データベースへのアクセスを保有していたケース。その後、テストデータが誤って本番環境に残り、決算データが汚染されるリスクが生じた。これはIT一般統制の「変更管理」領域の不備と、「アクセス管理」領域の不備の複合的な結果。
Tier 2：標準が要求する実装ポイント
ISA 315.34に準拠するためには、単にIT統制が「存在すること」ではなく、「機能していること」を監査人が検証する必要がある。存在するが運用されていないアクセス管理ポリシーは、統制とは言えない。実務では、権限付与から90日以内に実装されなかったアクセス権が放置されている例が多い。ISA 315.A73で「定期的なレビュー」が求められているのはこのためだが、年1回の棚卸しだけで済ませるチームが大多数。
Tier 3：実装上の一般的な課題
IT一般統制の文書化が、ITチームだけに留まり、監査チームが検証しにくい技術文書（ネットワークダイアグラム、コンフィグ設定ファイル）で提供されるケース。監査人は、この技術資料を監査証拠として活用しようとするが、その信頼性をどう検証するかについて明確なガイダンスを持たない。また、クラウドベースのシステムが増えるにつれ、クラウドプロバイダーのSoC 2レポートに過度に依存する傾向がある。プロバイダーの統制が強固でも、企業自身のアクセス管理（誰がプロバイダーダッシュボードにアクセスするか）が甘ければ、リスクは顕在化する。
IT一般統制 vs. IT応用統制
自動化された統制（例：システムが自動計算する売上控除額）とIT一般統制の関係を理解することが重要。
IT一般統制は、ITシステム全体の信頼性を支える基礎。IT応用統制（Application Controls）は、特定の業務プロセス（売上計上、在庫計算、給与計算）の中で、特定の目的（売上の正確性、在庫金額の適切性）を達成するための統制。
IT一般統制が機能していなければ、個別のIT応用統制をいくら手厚くテストしても、その結果を信頼することはできない。例えば、変更管理が機能していなければ、売上計上ロジックがいつどのように変わったかが追跡できず、計算結果の信頼性に疑問が生じる。
ISA 330.A74では、この関係性が明示されている。監査人は、IT一般統制を評価した後、その評価結果に基づいてIT応用統制のテスト範囲・深さを決定する。一般統制が「低リスク」なら、応用統制のテストを効率化できる。一般統制が「高リスク」なら、応用統制の直接的なテスト（例：売上計上ロジックのホワイトボックステスト）が必要になる。
関連用語
- IT応用統制: 売上計上、給与計算など、特定の業務プロセスの正確性を確保するための統制。一般統制が基礎、応用統制が構造。
- 内部統制の評価: ISA 315全体の枠組み。IT一般統制はこの中の1つのコンポーネント。
- システムリスク: ITシステムの不備や障害が起因となる監査上のリスク。IT一般統制が弱いとシステムリスクが高まる。
- 自動化された統制: システムが自動実行する統制。その信頼性はIT一般統制に依存。
- 情報セキュリティと監査: セキュリティ統制とIT一般統制の交差領域。アクセス管理はその典型例。
- クラウドシステムの監査: オンプレミスと異なるIT一般統制の検証方法。SoC 2レポートの活用と限界。
関連ツール
テクレア・ジャパンの例で使用したアクセス管理テストおよび変更管理テストについては、IT一般統制評価チェックリストで段階的なテスト手順が提供されている。