IT全般統制（ITGC）とは？J-SOXの4領域・評価手続・不備事例を公認会計士が解説
川端 啓豊「監査法人からITGCの整備状況を聞かれたが、何をどこまで準備すればよいのかわからない」
「J-SOXの3点セットは作成したものの、IT統制の評価には着手できていない」
このような状況で、社内のすべてのシステムを対象にチェックリストを埋め始めるのは得策ではありません。
IT全般統制（ITGC）対応で最初に行うべきことは、J-SOXの評価対象となる業務プロセスと、それを支えるシステムとのつながりを整理することです。そのうえで、財務報告に関連するシステムについて、開発・変更、運用、アクセス、外部委託の管理状況を確認します。
本記事では、監査法人からITGC対応を求められた経理・内部監査・情報システム部門の担当者に向けて、次の内容を実務に沿って解説します。
- IT全般統制の定義とJ-SOXにおける位置づけ
- 評価対象となる4つの領域と代表的な統制項目
- 評価対象システムとIT基盤の決め方
- 整備状況評価・運用状況評価の進め方
- 特権IDをはじめとする、よくある不備と対策
記事を読み終える頃には、自社で優先して確認すべき事項が整理できます。
IT全般統制（ITGC）とは
IT全般統制（ITGC：IT General Controls）とは、IT業務処理統制が有効に機能する環境を支える統制活動です。通常、個々の取引ではなく、複数の業務処理に共通するIT基盤を単位として整備・評価します。
たとえば、会計システムに「承認されていない仕訳は登録できない」「販売データを自動で会計帳簿へ連携する」といった機能があっても、そのシステムが次の状態であれば、処理結果の信頼性に疑問が生じます。
- 承認を受けずにプログラムや設定を変更できる
- 退職者や異動者のID・権限が残っている
- 管理者IDを複数人で共有し、操作した人物を特定できない
- バックアップは取得しているが、復元できるか確認していない
ITGCは、このようなリスクに対応し、システムの開発・変更、運用、アクセス、外部委託が適切に管理されるための土台です。
実務では、財務報告に関連するIT統制を「IT全社的統制」「IT全般統制」「IT業務処理統制」の3つに分けて整理することが多くあります。
IT業務処理統制（ITAC）との違い
ITGCと一緒に登場するのが、IT業務処理統制（ITAC：IT Application Controls）です。両者の違いは、次のとおりです。
| 観点 | IT全般統制（ITGC） | IT業務処理統制（ITAC） |
|---|---|---|
| 対象 | システム基盤や運用環境 | 個々の取引・業務処理 |
| 目的 | ITACが継続して機能する環境を支える | 承認された取引が正確・網羅的に処理されることを担保する |
| 代表例 | 変更管理、ID・権限管理、ジョブ管理、バックアップ、委託先管理 | 入力チェック、自動照合、承認ワークフロー、自動計算 |
| 主な評価単位 | IT基盤、管理体制 | 業務プロセス、統制機能 |
重要なのは、ITACがITGCに支えられている点です。たとえば自動計算機能が正しく設計されていても、承認を経ずにプログラムを変更できるのであれば、その機能が評価期間を通じて同じように動いていたとは限りません。
ただし、ITGCに不備があれば、関連するすべてのITACへ直ちに依拠できなくなるわけではありません。不備の内容、影響を受けるシステムや統制、補完統制の有無、リスクが実際に発現していないことを確認できるかを検討します。変更管理に不備があっても、対象期間中に関連プログラムの変更がなかったことを確認できるなど、影響が限定される場合があります。
IT全社的統制との関係
IT全社的統制は、IT戦略、情報セキュリティ方針、IT部門の組織・責任、リスク評価、モニタリングなど、組織全体のIT統制環境に関する方針と手続です。
- IT全社的統制：会社全体のIT方針・体制・モニタリング
- IT全般統制：IT基盤を支える日常的な管理活動
- IT業務処理統制：業務プロセスに組み込まれた自動処理や自動チェック
この3つを分けて考えると、規程や方針だけを確認してITGC評価を終えてしまう、あるいはシステムの設定だけを確認して全社的な管理体制を見落とすといった混乱を防げます。
なぜITGCが重要なのか
ITGCの有効性は、自動統制やシステムから出力される情報に、どの程度依拠できるかに影響します。
- ITGCが有効な場合：自動統制が期間を通じて一貫して機能したことを、効率的に評価しやすくなります。
- ITGCに不備がある場合：不備の影響分析に加え、補完統制の評価、プログラム変更の有無の確認、手作業による統制の追加評価などが必要になる場合があります。
- 結果として：会社側の評価工数と監査工数が増え、是正が期末までに間に合わないリスクも高まります。
ITGCの不備が見つかった場合は、ほかの統制によってリスクが低減されているか、財務報告へどのような影響があるかを含めて評価します。したがって、ITGCの不備だけを理由に、直ちに「開示すべき重要な不備」と判断するものではありません。
一方で、変更申請、承認、アクセス権限の棚卸などの証跡は、後からまとめて作ることが難しいものです。特にIPO準備企業では、上場申請期になってから統制を整備しても、必要な運用実績を十分に示せない可能性があります。早い段階で対象範囲と不足事項を把握し、日常業務の中で証跡が残る仕組みを作ることが重要です。
ITGCの4つの領域と統制項目一覧
実施基準では、IT全般統制を評価する際の例として、次の4領域が示されています。
- システムの開発・保守
- システムの運用・管理
- アクセス管理
- 外部委託
会社のシステム構成やリスクによって必要な統制は異なるため、以下の項目をすべて機械的に導入するのではなく、自社のリスクに応じて取捨選択します。
1．システムの開発・保守
プログラムやシステム設定の変更が、申請、承認、テスト、本番移行の手順を経て実施されることを担保する領域です。
| 統制項目 | 統制の内容例 | 主な証跡 |
|---|---|---|
| 変更の申請・承認 | 変更目的、対象、影響、実施予定を記載し、責任者が事前承認する | 変更管理台帳、チケット、承認記録 |
| テスト | 本番移行前にテストを行い、必要に応じて利用部門が結果を確認する | テスト計画、結果、利用部門の承認 |
| 本番移行 | 承認済みの変更だけを本番環境へ反映する | リリース承認、移行ログ |
| 環境・権限の分離 | 開発者が承認なく本番プログラムを直接変更できないようにする | 環境構成図、権限一覧、操作ログ |
| 緊急変更 | 緊急時の例外手順と、事後承認・レビューの期限を定める | 緊急変更記録、事後承認 |
つまずきやすい点：小規模な組織では、開発者とリリース担当者を完全に分けられないことがあります。その場合は、責任者がリリース内容とログを事後レビューするなど、リスクを補う統制を検討します。職務分掌ができないこと自体ではなく、残るリスクへどう対応するかが論点です。
2．システムの運用・管理
システムが安定して稼働し、財務報告に関連するデータが適切に処理・保全されることを担保する領域です。
| 統制項目 | 統制の内容例 | 主な証跡 |
|---|---|---|
| ジョブ管理 | バッチ処理の結果を監視し、異常終了時に調査・再処理する | ジョブログ、監視記録、再処理記録 |
| バックアップ | 対象、頻度、保管期間を定めてバックアップを取得する | 設定情報、取得ログ |
| リストア確認 | 重要度に応じて復元テストを行い、実際に利用可能か確認する | リストアテスト計画・結果 |
| 障害・インシデント管理 | 障害を記録し、影響、原因、対応、再発防止策を管理する | インシデント台帳、報告書 |
つまずきやすい点：「バックアップが成功した」というログだけを保存し、復元可能性を一度も確かめていないケースがあります。バックアップの目的はデータを取得することではなく、必要なときに復元できる状態にすることです。
3．アクセス管理
「誰が、どのシステムやデータに対して、何をできるか」を管理する領域です。人事異動、退職、兼務、プロジェクト参加など、人の動きと連動させる必要があります。
| 統制項目 | 統制の内容例 | 主な証跡 |
|---|---|---|
| IDの付与・変更・削除 | 申請・承認に基づいて処理し、退職・異動時は期限内に削除・変更する | ID申請、承認、処理完了記録 |
| 特権IDの管理 | 付与対象者を限定し、必要に応じて利用申請または操作ログのレビューを行う | 特権ID一覧、利用申請、ログレビュー |
| 権限の定期棚卸 | 在籍状況と職務に照らして、不要なID・権限がないか確認する | 棚卸結果、是正記録、責任者承認 |
| 認証設定 | パスワード、多要素認証、ロックアウトなどをリスクに応じて設定する | 設定画面、設定値の一覧 |
| 職務分掌 | 取引の登録と承認など、相反する権限の同一人物への集中を防ぐ | 権限マトリクス、例外承認 |
| 物理的アクセス | サーバー室などへの立入りを制限する | 入退室権限一覧、入退室記録 |
つまずきやすい点：人事部門は退職・異動を把握していても、情報システム部門への連絡が遅れたり、連絡対象となるシステムが漏れたりすることがあります。人事情報とシステムのユーザー一覧を定期的に突合すると、連携漏れを発見しやすくなります。
4．外部委託に関する契約の管理
システム開発・運用の委託先やクラウドサービス事業者が担う業務について、必要な統制が実施されているかを管理する領域です。
| 統制項目 | 統制の内容例 | 主な証跡 |
|---|---|---|
| 委託先の選定 | 業務内容とリスクに応じて、委託先の能力・セキュリティ等を確認する | 選定記録、質問票、評価結果 |
| 契約・SLA | 責任分界、セキュリティ、障害対応、監査権限などを明確にする | 契約書、SLA |
| 継続的モニタリング | サービス実績、障害、変更などを定期的に確認する | 定例報告、会議議事録、評価記録 |
| 保証報告書の利用 | 必要に応じてSOC1レポート等を入手し、対象範囲、対象期間、例外事項を検討する | SOC1レポート、検討調書 |
| 委託会社側の統制 | SOCレポートに記載された委託会社側の統制を自社で実施する | CUEC対応表、実施証跡 |
つまずきやすい点：SOC1レポートを入手しただけで評価を終えてしまうケースがあります。自社が利用するサービスや機能が報告書の対象に含まれるか、対象期間に空白がないか、例外事項が自社に影響するか、委託会社側の統制（CUEC）を実施しているかまで確認する必要があります。
ITGCの評価範囲を決める4つのステップ
J-SOX対応だからといって、社内で使用するすべてのシステムをITGCの評価対象にするわけではありません。金融庁の「内部統制報告制度に関するQ&A」問38でも、対象は財務報告に係る内部統制に関連するシステムであることが示されています。
ステップ1．評価対象となる業務プロセスを確認する
重要な事業拠点における業務プロセス、重要な勘定科目に関連する業務プロセス、決算・財務報告プロセスなど、J-SOXの評価範囲を確認します。
ステップ2．業務プロセスで使うシステムを洗い出す
業務記述書、フローチャート、RCMを手掛かりに、取引の発生から集計・記帳・財務報告までに利用するシステムを特定します。販売、購買、在庫、会計、連結、給与などのシステムに加え、システム間のインターフェースも確認します。
ステップ3．システムに依存する統制・情報を特定する
RCM上の統制のうち、自動統制、システムで設定された承認ワークフロー、システム出力帳票に依存する手作業統制などを特定します。帳票を人がレビューする統制であっても、帳票の完全性・正確性がシステムに依存する場合は、その生成過程の検討が必要です。
ステップ4．IT基盤と評価単位を整理する
対象システムが稼働するOS、データベース、クラウド環境、運用組織、規程・手順、外部委託先などを整理します。同じIT基盤・管理体制で運用される複数システムは、共通するITGCをまとめて評価できる場合があります。
一方、同じSaaS製品を利用していても、子会社ごとにID管理や設定変更の手続が異なれば、同じ評価単位にまとめられないことがあります。評価単位の括り方は工数に大きく影響するため、計画時に監査法人と認識を合わせておくことが重要です。
ITGCの評価手続
ITGCの評価は、大きく「整備状況評価」と「運用状況評価」に分かれます。
整備状況評価
整備状況評価では、想定するリスクに対して統制が適切に設計され、実際に業務へ組み込まれているかを確認します。規程が存在するだけでは足りません。
- IT管理規程、アクセス管理手順、変更管理手順などを閲覧する
- 統制の責任者・実施者へ質問する
- 実際の変更やID申請を1件選び、開始から完了まで追跡する
- 規程、担当者の説明、実際の運用が一致しているか確認する
初年度やシステム刷新時は、ウォークスルーによって「承認者が不明確」「緊急変更の手続がない」「人事異動の連絡経路が定まっていない」といった設計上の穴を早期に見つけることが重要です。
運用状況評価
運用状況評価では、設計された統制が評価期間を通じて実際に運用されていたかを、証跡とサンプルを使って検証します。
- 統制の実施件数を示す母集団を入手する
- 母集団の完全性を確認する
- 頻度やリスクに応じてサンプルを抽出する
- 実施者、承認者、実施日、確認内容、例外対応を検証する
- 発見した例外が単発か、母集団全体へ波及するかを評価する
運用評価のサンプル件数の目安
手作業による統制では、実施頻度に応じて次のような件数が目安として使われることがあります。
| 統制の実施頻度 | サンプル件数の例 |
|---|---|
| 1日につき多数回・日次 | 25件 |
| 週次 | 5件 |
| 月次 | 2件 |
| 四半期 | 2件 |
| 年次 | 1件 |
これは一律のルールではありません。統制の重要性、複雑性、実施者の判断の程度、過年度の結果、監査法人の方針などによって必要な件数は変わります。
自動化された統制は、関連するITGCが有効であり、対象期間中にプログラムや設定の変更がないことなどを確認できれば、1件の検証を基本とする場合があります。反対に、設定変更が多い、手作業が介在する、ITGCに不備があるといった場合は、追加手続が必要になることがあります。
期中に運用評価を行った場合は、その後の期間について、統制やシステムに重要な変更がないかを質問、変更記録の閲覧、必要に応じた追加サンプルなどで確認します。具体的な手続は、残余期間の長さとリスクに応じて決定します。
ITGCでよくある不備と改善方法
| よくある不備 | 主なリスク | 改善の方向性 |
|---|---|---|
| 退職者・異動者のIDや権限が残っている | 不要なアクセスや不正操作 | 人事イベントとの連携、定期棚卸、人事情報との突合 |
| 特権IDを複数人で共有している | 操作実施者を特定できない | 個人ID化、貸出管理、ログレビュー |
| 開発者が本番環境を直接変更できる | 未承認変更や誤変更 | 権限分離、移管承認、操作ログの独立レビュー |
| 権限棚卸の証跡が残っていない | レビュー範囲・結論を確認できない | 対象一覧、確認者、確認日、結果、是正内容を記録 |
| 緊急変更が通常手続を迂回したままになっている | テスト・承認が不十分 | 例外条件、事後承認期限、レビュー項目を明文化 |
| SOC1レポートを入手していない、または閲覧して評価していない | 委託先の統制を評価できない | 早期入手、スコープ・例外・CUECの検討 |
これらに共通するのは、「ルールはあるが証跡がない」「例外処理が日常化している」「部門間の連絡に依存しすぎている」という問題です。
ITGCでは、規程を増やすことよりも、チケット管理やワークフローを使って申請、承認、実施、レビューの記録が日常業務の中で残るようにする方が、継続的な運用につながります。評価のためだけに別の証跡を作る運用は、担当者の負担が大きく、形骸化しやすいためです。
特に注意したい特権IDの管理
事業会社での内部統制評価と監査法人でのIT監査に携わってきた経験上、特に注意が必要な領域の一つが、特権ID・管理者権限の管理です。
見落とされやすいのは、退職者の削除漏れだけではありません。実務では、在籍者が業務上不要になった権限を持ち続けているケースもあります。
- 情報システム部門から他部門へ異動した後も、管理者権限が残っている
- プロジェクト対応で一時付与した権限を、終了後も回収していない
- 兼務の解消後も、旧担当業務のシステムへ強い権限でアクセスできる
- ベンダー保守用IDを常時有効にし、利用状況を確認していない
特権IDは、通常の承認ワークフローを迂回してデータや設定を変更できる場合があります。そのため、付与時の承認だけでなく、利用目的、利用期間、操作記録、定期棚卸を組み合わせて管理することが重要です。
棚卸の起点には、退職だけでなく、異動、兼務解消、プロジェクト終了、委託契約終了を含めます。人事部門の情報だけでは外部委託先や一時利用者を把握できないため、システム責任者・委託先管理部門との連携も必要です。
2023年の内部統制基準・実施基準改訂とITGC
2023年4月に公表された内部統制基準・実施基準の改訂は、2024年4月1日以後に開始する事業年度から適用されています。
改訂では、ITの委託業務に係る統制の重要性が増していることや、サイバーリスクの高まりを踏まえた情報システムのセキュリティ確保の重要性が示されました。
SaaSやクラウドサービスを広く利用する現在は、システムのすべてを自社で管理するのではなく、サービス事業者と利用会社が役割を分担します。オンプレミス環境を前提に作った古い規程をそのまま使用していると、実際の責任分界や運用と規程が一致しないことがあります。
- 誰がIDの発行・削除を行うのか
- 設定変更とプログラム変更のうち、自社が管理する範囲はどこか
- 障害時に、事業者からどのような報告を受けるのか
- SOCレポート等で、委託先の統制をどこまで確認できるのか
- 利用会社側で実施すべき統制は何か
クラウド利用の有無だけで評価要否を決めるのではなく、そのサービスが財務報告に関連するか、自動統制やシステム生成情報に依拠するか、事業者と自社の責任分界がどうなっているかを確認することが大切です。
IT全般統制に関するよくある質問
情報システム担当者が1名しかいない場合、職務分掌はどうすればよいですか
開発、運用、本番移行を完全に分離できない場合でも、直ちに対応不能になるわけではありません。システム責任者や業務部門責任者によるリリース承認、操作ログの事後レビュー、変更内容と申請内容の照合など、残るリスクを低減する統制を設計します。
形式的に承認者を置くだけではなく、その人が変更内容を理解し、異常を発見できる情報を受け取れるかが重要です。補完統制で十分かどうかは、自社のシステムとリスクを踏まえて監査法人と協議します。
会計システムがSaaSでもITGCの評価は必要ですか
SaaSという理由だけで、すべてのサービスが同じように評価対象になるわけではありません。財務報告上重要なサービスであり、その自動統制やシステム生成情報に依拠する場合は、関連するITGCが評価対象になり得ます。
事業者側のインフラ運用やプログラム変更はSOC1レポート等を利用して検討し、自社側ではID・権限管理、承認設定、マスタ設定、CUECなどを評価するという役割分担が一般的です。利用する機能と契約形態によって範囲が異なるため、サービス名だけで判断しないことが重要です。
ITGCに不備があると、開示すべき重要な不備になりますか
ITGCの不備が見つかっただけで、直ちに開示すべき重要な不備になるわけではありません。不備が影響するシステム・統制・勘定科目、虚偽記載が発生する可能性と金額的・質的重要性、補完統制の有無などを総合的に評価します。
一方、影響範囲が広い特権ID、未承認の本番変更、重要なインターフェース処理などの不備は、複数の業務プロセスに影響する可能性があります。発見後は不備の名称だけで判断せず、影響分析と是正計画を早期に行う必要があります。
まとめ｜ITGC対応は「対象範囲」と「証跡が残る運用」の設計から
- ITGCは、IT業務処理統制が継続して機能する環境を支える統制である
- 主な評価領域は、開発・保守、運用・管理、アクセス管理、外部委託管理の4つ
- すべての社内システムではなく、財務報告に関連するシステムとIT基盤を対象にする
- ITGCの不備があっても、影響分析や補完統制を検討せず一律に結論づけない
- 特権IDは、退職だけでなく異動、兼務解消、プロジェクト終了、委託終了も見直しの契機にする
- 規程を増やすだけでなく、申請・承認・実施・レビューの証跡が日常業務で残る仕組みを作る
ITGC対応では、チェックリストの項目を増やすことよりも、財務報告リスクとのつながりを踏まえて評価範囲を決め、実行可能な統制を設計することが重要です。
当社では、J-SOX対応(IT統制を含む)の評価支援を行っています。「何から着手すべきか診断してほしい」という段階でも構いません。まずはお気軽に無料相談をご利用ください。
投稿者プロフィール
-
公認会計士・システム監査技術者・公認情報システム監査人（CISA）
福岡県出身。東京大学法学部卒業。
本田技研工業株式会社（Honda）入社後、内部統制の構築・運用および内部監査の高度化に従事。
その後、大手監査法人やコンサルティング会社等において、会計監査・IT監査等の現場責任者として、幅広い企業の内部統制構築・評価・改善を支援。
事業会社・監査法人の双方で培った知見を活かし、現場目線でのガバナンス支援を提供します。
