IT全般統制（ITGC）とは｜監査人の着眼点と評価範囲の落とし穴
目次
本稿は、金融庁「財務報告に係る内部統制の評価及び監査に関する実施基準」(2023年4月改訂)と、経済産業省「システム管理基準 追補版」(2024年12月に17年ぶりに改訂)の2つの一次情報に基づいて、ITGCを実務の順序で解説します。
まず、定義から確認します。
1. IT全般統制（ITGC）とは
IT全般統制（Information Technology General Controls：ITGC）は、金融庁の「財務報告に係る内部統制の評価及び監査に関する実施基準」に定義が置かれています。
ＩＴに係る全般統制とは、業務処理統制が有効に機能する環境を保証するための統制活動を意味しており、通常、複数の業務処理統制に関係する方針と手続をいう。 【出典】金融庁「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）」（令和5年4月7日）
同じ箇所で、具体例として4つの項目が挙げられています。
システムの開発、保守に係る管理
システムの運用・管理
内外からのアクセス管理などシステムの安全性の確保
外部委託に関する契約の管理
ITGCの4つの領域に関する詳細はこちら
実務上ほとんど意識されていませんが、この4項目は実施基準に、異なる表記で登場します。
定義部分 （Ⅰ.2(6)②〔ITの統制〕ロa） | 評価部分 （Ⅱ.3(3)⑤ニa） | 監査人側 （Ⅲ.4(2)②ロ） | |
システムの開発、保守に係る管理 | システムの開発、保守 | システムの開発、変更・保守 | |
2 | システムの運用・管理 | システムの運用・管理 | システムの運用・管理 |
3 | 内外からのアクセス管理などシステムの 安全性の確保 | 内外からのアクセス管理などのシステムの安全性の確保 | システムの安全性の確保 |
4 | 外部委託に関する契約の管理 | 外部委託に関する契約の管理 | 外部委託に関する契約の管理 |
ものによって表記が揺れているのは、上記が混在して引用されているためです。実質的な違いはありません。
ITGCは「システム単位」ではなく「IT基盤単位」で構築する
ITGCを理解するうえで最も重要なのは、構築の単位です。実施基準は、ITGCは業務を管理するシステムを支援するIT基盤（ハードウェア、ソフトウェア、ネットワーク等）を単位として構築するものと説明しています。
たとえば購買・販売・物流の3つの業務管理システムが1つのホスト・コンピュータで集中管理され、すべて同一のIT基盤の上で稼働しているなら、そのIT基盤に有効なITGCを構築することで3業務の情報の信頼性を高められます。一方、3つが異なるIT基盤の上で動いている場合、基盤を管理する部門や運用方法が異なると考えられるため、それぞれのIT基盤ごとにITGCを構築する必要があります。
ここが「システムごとに評価する」IT業務処理統制との決定的な違いであり、第3章で扱う評価範囲の話に直結します。
IT基盤には実施基準上の定義がない
実施基準にはIT基盤という用語が繰り返し登場しますが、明確な定義は置かれていません。経済産業省の「システム管理基準 追補版（財務報告に係るIT統制ガイダンス）」は、この点を補い、IT基盤を、ITに関与する組織の構成、ITに関する規程及び手順書等、ハードウェア・ソフトウェア・ネットワークの各構成、関連する外部委託を含むものとして解釈しています。
実務Tips：IT基盤の把握項目として、実施基準は6つを挙げています。ITに関与する組織の構成／ITに関する規程・手順書等／ハードウェアの構成／基本ソフトウェアの構成／ネットワークの構成／外部委託の状況。子会社への照会票をゼロから作る必要はありません。追補版の付録には「IT基盤質問書」の記載例があり、そのまま雛形として使えます。
2. ITGC・ITAC・IT-ELC——3層構造の理解
IT業務処理統制（ITAC）との違い
IT業務処理統制（ITAC）は、業務を管理するシステムにおいて、承認された業務がすべて正確に処理・記録されることを確保するために業務プロセスに組み込まれた統制です。実施基準は具体例として、入力情報の完全性・正確性・正当性等を確保する統制、例外処理（エラー）の修正と再処理、マスタ・データの維持管理、システム利用に関する認証や操作範囲の限定などのアクセス管理を挙げています。
整理すると、ITACは「その処理が正しいこと」を担保する統制、ITGCは「ITACが働き続ける環境」を担保する統制です。ITACはシステムごとに識別・評価し、ITGCはIT基盤ごとに識別・評価します。
IT全社的統制（IT-ELC）は実施基準にない用語
解説記事でしばしば登場する「IT全社的統制」は、実施基準には存在しない用語です。実施基準が定めているのはITGCとITACの2区分のみです。
3層に整理しているのは経産省の追補版で、ITに直接係る部分とそれ以外を区別する目的で、IT全社的統制を「企業の統制が全体として有効に機能する環境を保証するためのITに関連する方針と手続等、情報システムを含む内部統制」として位置づけています。
実施基準の側では、全社的な内部統制の評価項目の例（参考1）のなかに「ITへの対応」として5つの項目が掲げられており、これが実質的にIT全社的統制に相当します。
ITに関する適切な戦略、計画等を定めているか
内部統制を整備する際に、IT環境を適切に理解し、これを踏まえた方針を明確に示しているか
手作業とITを用いた統制の利用領域について、適切に判断しているか
ITを用いて統制活動を整備する際に、ITを利用することにより生じる新たなリスクが考慮されているか
ITGCおよびITACについての方針及び手続を適切に定めているか
用語を使い分ける実益：監査法人との会話では「ITGC」「ITAC」で足ります。一方、社内の規程体系やRCMを設計するときは、方針レベル（全社）と実施レベル（基盤）を分けておくほうが管理しやすいため、追補版の3層区分が有効です。追補版は、外部サービス管理・事業継続管理・人的資源管理について、方針策定部分は全社的統制、対策実施部分は全般統制と切り分ける考え方を示しています。
ITGCが有効でも、ITACが有効という結論にはならない
2023年4月の改訂で、実施基準に次の一文が新設されました。
なお、ＩＴに係る全般統制は、業務処理統制が有効に機能する環境を確保するものであるが、ＩＴに係る全般統制が有効に機能していると評価されたとしても、それだけでＩＴに係る業務処理統制も有効に機能しているという結論に至らない点について留意することが必要である。 【出典】金融庁「財務報告に係る内部統制の評価及び監査の基準・実施基準（抄）新旧対照表」（令和5年4月7日）
この一文は、評価計画の作り方に直接影響します。ITGCの評価に工数を投じ、有効という結論を得たとしても、それはITACの評価を軽くする根拠にはなりません。両者が相互に作用するのは、次の3つの局面です。
ITGC → ITAC の方向（ITGCの有効性がITACの評価を軽くする）
ITを利用した内部統制の整備状況が有効と評価された場合に、ITGCの有効性を前提として、人手による内部統制よりもサンプル件数を減らし、サンプルの対象期間を短くできる
自動化されたITACについて、過年度の評価結果を継続利用できる
ITAC → ITGC の方向（ITACの評価範囲拡大がITGCの運用評価を代替する）
ITACの運用状況の評価の実施範囲を拡大することにより、ITGCの運用状況の評価を実施せずに、内部統制の運用状況の有効性に関して十分な心証が得られる場合がある
1と2は「評価の量を減らせる」話であって、「評価しなくてよい」話ではありません。 一方、3は2023年改訂前から置かれている記述で、ITGCの運用評価そのものを省略し得る唯一の経路です。ITGCの整備が追いついていない初年度に、ITAC側を厚く見ることで乗り切るという設計は、制度上の裏付けを持ちます。ただし「実施せずに済む場合もある」という書きぶりであり、適用には監査人との事前合意が前提になります。
逆方向の関係は成立します。ITGCに不備があれば、ITACが有効に機能するよう整備されていたとしても、その有効な運用を継続的に維持できない可能性が生じます。関係は非対称であることを押さえてください。
3層構造とITGC・ITACの関係図
3. 評価範囲の決め方
出発点は内部統制全体の評価範囲
ITGCの評価範囲は、内部統制の評価範囲の内側で決まります。重要な事業拠点を選定し、企業の事業目的に大きく関わる勘定科目に至る業務プロセスを識別し、そのプロセスで使われるアプリケーション・システムと、それを支えるIT基盤が範囲に入る、という順序です。
なお2023年改訂では、拠点選定の指標について、連結売上高等のおおむね3分の2という水準や、売上・売掛金・棚卸資産の3勘定という例示を機械的に適用すべきでないことが明記されました。ここは範囲を絞る根拠として長年使われてきた箇所であり、従来どおりの運用を続けている場合は説明の見直しが必要です。
IT基盤は事業拠点と一致しない
ITGCの評価範囲で最も見落とされるのがここです。追補版は、組織区分とIT基盤が一致しないケースとして、IT基盤が別の子会社に所属するデータセンターやクラウドサービスで運用されている場合には、その子会社の売上高に関係なく、当該データセンターやクラウドサービスも評価範囲に含めることになるという考え方を示しています。
売上高基準で「この子会社は範囲外」と整理していても、その子会社がグループの基幹システムの基盤を運用しているなら、基盤としては範囲に入り得るということです。IT基盤は事業拠点の中に複数存在することもあり、複数の事業拠点に共通することもあります。組織図から範囲を導くのではなく、評価対象となるアプリケーション・システムとの関係から整理するのが正しい手順です。
小規模拠点のシステムが売上計上の要になっている
追補版は、組織区分とアプリケーションが一致しない例として、売上計上の重要なポイントである出荷情報の発生が特定の子会社の在庫管理システムで行われている場合を挙げ、この場合には当該子会社の売上高にかかわらず、その出荷業務を評価範囲に含めることになるとしています。
評価単位（IT基盤）をどう切るか
実施基準は、ITGCについてIT基盤の概要をもとに評価単位を識別するとし、具体例として次を示しています。自社開発の販売・購買・物流のシステムはシステム部が管理し、会計システムは経理部が市販のパッケージ・ソフトウェアを導入・管理している場合、評価単位を「システム部」と「経理部」の2つとして識別する、という例です。
つまり評価単位は、管理主体と管理方法の違いで割れると考えるのが基本です。実務では次の観点で分割の要否を検討します。
システムによって開発手順や変更管理手順が異なる
システムによって運用業務の担当部署が異なる
機器の設置場所が自社と外部データセンターに分かれている
セキュリティに関する方針・手続が部門によって異なる
評価単位が増えれば、そのまま工数が増えます。逆に、単位を無理に1つにまとめると、実態と異なる評価になり、後で分割を求められます。ここは初年度の設計で最も慎重に判断すべき箇所です。
決算・財務報告プロセスとスプレッドシート
決算・財務報告プロセスに係るITは、原則としてすべて評価範囲に含まれます。追補版は、このプロセスでは財務会計システムや連結決算システムのほかにスプレッドシート等を利用する場合があり、計算式のコピー忘れや計算式の誤りが財務報告の正確性・網羅性に直接影響するため、スプレッドシート等の統制についても評価することになるとしています。
監査人との協議は「範囲決定前」に
2023年改訂で、評価範囲に関する監査人との協議が基準本文に位置づけられ、協議のタイミングとして、評価の計画段階と、状況の変化等があった場合の2つが明確化されました。協議は監査人による指導的機能の一環であり、範囲を決めるのは経営者であるという前提も併記されています。
追補版も、事業年度のできる限り早い時期に、評価すべきIT基盤を決定するまでに外部監査人とIT基盤について協議し、認識を一致させておくことが望まれるとしています。期末に範囲の認識違いが判明すると、是正の時間が残りません。
評価範囲の決定フローと、そこから漏れやすいIT基盤の例
4. ITGC——各領域の詳細
追補版は、ITGCの統制項目を4領域それぞれについて細目まで示しています。以下は、その細目と、実務でつまずきやすい点を対応させたものです。
(1) システムの開発、保守
開発・保守に関する手続の策定、ソフトウェアの開発・調達、IT基盤の構築、検証（テスト）が細目です。
証跡として残すべきものは、要件定義書とプログラム仕様書、テスト計画とテスト結果、本番移行の承認記録です。追補版は、テストには開発当事者以外の者（運用担当者や保守担当者等）が参画することを統制目標として挙げています。受入テストを開発担当者が実施していると、誤りや不正が見逃される可能性が残るためです。
落とし穴：パッケージソフトを変更せずに使っている場合、開発リスクは限定されます。ただし追補版は、購入したままの状態では十分な統制が実現できないことに注意すべきとし、アカウント管理や権限の設定、自動仕訳の設定、仕訳の承認者の設定、セグメント別開示に関わる組織の設定、他システムからのデータ連携の設定などを適切に行わなければ、統制が存在することにはならないと指摘しています。「パッケージだからITGCは軽い」という理解は成立しません（この点は第7章で監査人側の記述とあわせて再度触れます）。
(2) システムの運用・管理
運用管理に関する手続の策定、構成管理・変更管理、データ管理が細目です。
変更管理では、緊急変更の扱いが典型的な弱点になります。追補版は、緊急の変更依頼も文書化された正式な変更管理手続に従うこと、緊急変更のための手続に取消手続があること、すべての緊急変更がテストされ変更後に標準的な承認手続に従っていることを確認するとしています。平時の変更管理は整っていても、緊急時の記録が残っていない組織は少なくありません。
本番移行については、移行を責任者が承認し、移行作業にあたって権限の分離が行われていることが求められます。開発者が本番環境に移行できる構成は、指摘を受けやすい代表例です。
データ管理では、バックアップの取得だけでなく、バックアップ媒体からの復旧をテストすることが統制目標に含まれています。取得の記録はあってもリストアテストの記録がない、というケースが頻出します。
(3) 内外からのアクセス管理などのシステムの安全性の確保
情報セキュリティフレームワーク、アクセス管理等のセキュリティ対策、情報セキュリティインシデントの管理が細目です。
追補版が挙げる統制目標のうち、実務で押さえるべきものは次の4点です。
職務権限に対応したアクセス範囲・アクセス権限のレベルを決めている
担当者の役割・職務の変更や離職の場合には、直ちにアクセス権が解除されている
担当者IDは適宜点検され、長期間利用されていないIDが削除され、その記録が保管されている
特権IDの付与にあたっては、担当者や利用期間を限定し、そのIDに対する業務にのみ利用している
特権IDについて追補版はさらに踏み込み、特権IDがすべての機能を利用できる場合には、スプリットパスワードや相互監視（デュアルコントロール）といった別の統制が併用されていることを確かめるとしています。
落とし穴：レガシーシステムやベンダー提供のサービスアカウントなど、構造上すぐに共有IDを廃止できないケースは現実に存在します。この場合、廃止を前提に計画を立てるよりも、利用申請と作業記録のレビューを組み合わせて発見的統制で補う設計のほうが、期限内に整備を完了できます。
(4) 外部委託に関する契約の管理
外部委託先との契約、サービスレベルの定義と管理、契約に基づく管理が細目です。第5章で詳述します。
4領域×主要統制×典型的証跡の対応表
5. クラウド・SaaS時代の委託先管理
2023年改訂で、IT委託が委託業務の例示に明記された
委託業務の評価について、実施基準の例示に情報システムの開発・運用・保守などITに関する業務を外部の専門会社に委託する場合が追加されました。従来の例示は、取引の承認・実行・計算・集計・記録や開示事項の作成といった業務の委託が中心でした。
あわせて「ITへの対応」の解説にも、ITに関する業務の全部または一部を外部組織に委託するケースがあり、ITの委託業務に係る統制の重要性が増していること、クラウドやリモートアクセス等の技術を活用するにあたってはサイバーリスクの高まり等を踏まえた情報システムのセキュリティ確保が重要であることが加えられています。
つまりクラウド・SaaSの利用は、制度上「委託業務の評価」の射程に正面から入ったということです。
委託しても責任は移らない
委託業務に関しては、委託者が責任を有しており、委託業務に係る内部統制についても評価の範囲に含まれる。 【出典】金融庁「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）」（令和5年4月7日）
評価範囲について、実施基準は「外部に委託した業務の内部統制については評価範囲に含める」とも注記しています。
モニタリング手段は3択
追補版は、受託会社の内部統制を評価する方法として3つを挙げています。
受託会社に質問書や確認書を送付する方式
直接往査する方式
受託会社の内部統制に関する保証報告書を入手して確認する方式
実施基準の側では、委託業務結果の報告書と基礎資料との整合性を検証し、結果の一部を企業内で実施して検証するサンプリングによる検証、および受託会社の評価結果を記載した報告書等を入手して自らの判断により評価の代替手段とする方法が示されています。後者について実施基準は、当該報告書等が十分な証拠を提供しているかどうかを検討しなければならないとしています。入手して添付するだけでは評価になりません。
SOC1とSOC2の使い分け
追補版のコラムが、この点を整理しています。SOC1は財務報告に限定した内部統制を対象とし、日本公認会計士協会の保証業務実務指針3402「受託業務に係る内部統制の保証報告書に関する実務指針」に該当します。SOC2はセキュリティ、可用性、処理の完全性、機密性、プライバシーに関する保証を提供するものです。
財務報告に係る内部統制の評価については基本的にSOC1レポートを利用することになりますが、追補版は、サイバーセキュリティリスクの増大も踏まえ、必要に応じてSOC2レポートを入手して委託先のセキュリティ等についての内部統制の状況を理解・評価することも重要としています。
利用時に確認すべき事項として、追補版は次を挙げています。当該保証報告がカバーしているシステムの種類と範囲、保証の主題、保証期間、提示時期、保証業務実施者の独立性や能力。
落とし穴：SOC2レポートに記載された補完的ユーザー統制（受託側の統制が有効に機能する前提として、利用者側で実施すべき統制）への自社側の対応が空白になっているケースが目立ちます。レポートを入手した時点で完了と考えず、補完的ユーザー統制の一覧を自社のRCMに突き合わせる作業まで行ってください。
契約と、既存契約の扱い
追補版は、契約書には必要に応じて委託業務に関する主要なリスクに対する統制方法や、その確認のための監査権（再委託先へのものを含む）を明記することを統制目標としています。また、外部委託先の拠点が国外にある場合には、その国や地域の法令・当局の規制に起因するリスクを勘案して判断することも挙げられています。
実務Tips：既存契約に監査権が入っていないSaaSは珍しくありません。この場合、契約改定を待つよりも、SOC1／SOC2の入手可否を先に確認し、入手できないサービスについてはそのサービスが財務情報のどこに効いているかを特定して、自社側の代替統制で補うほうが現実的です。契約改定は更新時期に合わせて計画すれば足ります。
委託形態別の責任分界とモニタリング手段のマトリクス
6. サイバーリスクとITGC
財務報告の文脈では、信頼性だけでなく可用性が問題になる
2023年改訂で、サイバーリスクの高まりを踏まえた情報システムのセキュリティ確保の重要性が、実施基準の「ITへの対応」に明記されました。ここで押さえるべきは、財務報告に係る内部統制におけるIT統制目標の構成です。
2023年改訂により、IT統制目標は次の4つになりました（従来あった「有効性及び効率性」が削除されています）。
準拠性：情報が関連する法令や会計基準、社内規則等に合致して処理されていること
信頼性：情報が組織の意思・意図に沿って承認され、漏れなく正確に記録・処理されること（正当性、完全性、正確性）
可用性：情報が必要とされるときに利用可能であること
機密性：情報が正当な権限を有する者以外に利用されないように保護されていること
追補版のコラムは、財務報告においてサイバーインシデントに起因した決算開示の遅延等が発生し、開示すべき重要な不備につながるといった問題も生じているとして、財務報告の信頼性の確保だけでなく可用性の確保も重要になっていると述べています。
ただし、制度上の射程には明確な限定がある
ここで同時に押さえておくべき記述が、IT統制目標の直後にあります。実施基準は、内部統制報告制度におけるIT統制は財務報告の信頼性を確保するために整備するものであり、それ以外の目的を達成するためのIT統制の整備・運用を直接的に求めるものではないとしています（Ⅰ.2(6)②〔ITの統制〕イ）。
この一文は、実務上2つの意味を持ちます。
ひとつは、セキュリティ対策をそのままJ-SOXの評価範囲に持ち込むことは制度の想定ではないということです。CSIRT体制、脆弱性診断、EDR導入といった施策は重要ですが、財務報告への影響経路を説明できないまま評価対象に積み上げれば、工数だけが増えます。範囲を絞る側の根拠として、この一文は使えます。
もうひとつは逆方向です。財務報告への影響経路が説明できる場合には、セキュリティ領域であっても評価対象から外せないということです。前節の事例は、可用性の毀損が開示の適時性を通じて財務報告に到達した経路を示しています。判断基準は「セキュリティか否か」ではなく「財務報告に効くか否か」です。
実際の開示事例に見る経路（業種・時期のみ）
2026年7月、食品・飲料業界の大手上場企業が、前事業年度（12月決算）の内部統制報告書に開示すべき重要な不備があり、財務報告に係る内部統制は有効でない旨を記載したことを公表しました。公表内容から読み取れる経路は次のとおりです。
サーバのデータ暗号化を伴うシステム障害が発生。調査の結果、攻撃者が管理者権限を不正に取得し、奪取したアカウントを不正利用してネットワーク内部を探索した後、複数のサーバでランサムウェアを実行したことが確認された
復旧対応と代替的な業務プロセスによる対応に時間を要し、決算作業に必要な財務報告関連データの取得・検証を含む一連の手続を適時に完了できず、有価証券報告書の提出期限の延長が必要になった
不備の所在は、「全社的な内部統制（情報システムの整備に関する方針）」の運用状況と評価された
原因は規程の不存在ではなく、規程類に基づく権限管理を含む運用管理の一部が、業務で使用する情報システム基盤の一部において十分に実施されていなかったこととされた
連結財務諸表および財務諸表の監査報告における監査意見は無限定適正意見
是正方針として公表されたのは、権限管理上の不備に対する是正、情報セキュリティ委員会の統括の下でのモニタリング体制の構築、そして重要な情報システムを対象とした規程類で求められる要件と実際の運用状況との差異を把握するための分析です。あわせて、財務報告に係る内部統制評価の対象として特定されているすべてのシステムにおいて、アクセス管理の厳格化やパスワードの強化等の対策を進めているとされています。
※本事例は2026年7月に公表された内部統制報告書および会社の適時開示に基づく整理であり、企業名は本稿では特定しません。また本節は公表内容の整理であって、当該企業の内部統制に対する評価や監査意見を述べるものではありません。
この事例から読み取れる3つの実務論点
第1に、財務数値の誤りがなくても不備になり得るという点です。監査意見は無限定適正であり、財務諸表の修正はすべて反映されたと判断されています。それでも、開示の適時性が損なわれたことをもって内部統制は有効でないと評価されました。ITGCを「数字が間違わないための統制」と理解していると、この経路は視界に入りません。
第2に、アクセス管理という典型的なITGC領域の問題が、最上位の不備として計上され得るという点です。本事例で不備が計上されたのは、ITGCではなく全社的な内部統制（情報システムの整備に関する方針）の運用状況でした。
実施基準は、開示すべき重要な不備となる全社的な内部統制の不備の例として、財務報告に係るITに関する内部統制に不備があり、それが改善されずに放置されている状態を挙げています（Ⅱ.3(4)①ハd）。ただし本事例は、この「放置」型には当てはまりません。不備は調査の過程で新たに識別されたものであり、それでも全社統制レベルの不備と評価されました。
つまり、ITGC領域の事象がどのレベルの不備として計上されるかは、放置の有無ではなく、影響範囲の広さと、どの統制の欠落が原因と整理されるかで決まるということです。規程は存在しており、欠けていたのは規程に基づく運用管理でした。原因を「方針・規程の運用」に求めれば全社統制、「個別基盤の統制活動」に求めればITGCに寄る。この切り分けは監査人との協議事項になります。
第3に、「規程はあるが運用されていない」が最も危険な状態であるという点です。是正方針の中心が要件と実運用の差異分析であることが、その裏返しです。整備状況の評価で規程の存在を確認して終わりにしていると、運用状況の評価まで到達しません。
内部監査部門が今期見るべき3点
規程と実運用の差異。とくに権限管理について、規程が求める要件と実際の設定を突き合わせる
管理者権限の棚卸。誰が保有しているか、期間限定になっているか、作業記録が残っているか
バックアップからの復旧の実績。取得記録ではなく、リストアテストの記録があるか
追補版は、サイバーインシデントが発生した場合には、攻撃を受けた領域から財務報告に関連する領域を整理・特定したうえで、当該領域のデータの信頼性への影響や流出可能性の程度を確認することが求められるとし、この確認においては顕在化している費用だけでなく将来の費用・損失の見積りが必要となる可能性にも留意が必要としています。
7. 監査人はITGCのどこを見るのか
実施基準は、経営者の評価に関する記述だけでなく、監査人がITGCをどう検討するかについても項目を列挙しています。ここを読んでいるかどうかで、監査法人との協議の生産性が大きく変わります。
システムの開発、変更・保守について監査人が留意する点
実施基準は、財務報告に関連して新たにシステム・ソフトウェアを開発、調達または変更する場合に、承認および導入前の試験が適切に行われているかを確認するとし、留意点として次を挙げています。
システム、ソフトウェアの開発、調達又は変更について、事前に経営者又は適切な管理者に所定の承認を得ていること ・開発目的に適合した適切な開発手法がシステム、ソフトウェアの開発、調達又は変更に際して、適用されていること ・新たなシステム、ソフトウェアの導入に当たり十分な試験が行われ、その結果が当該システム、ソフトウェアを利用する部門の適切な管理者及びＩＴ部門の適切な管理者により承認されていること ・新たなシステム、ソフトウェアの開発、調達又は変更について、その過程が適切に記録及び保存されるとともに、変更の場合には、変更前のシステム、ソフトウェアに関する内部統制の整備状況に係る記録が更新されていること ・新たなシステム、ソフトウェアにデータを保管又は移行する場合に、誤謬、不正等を防止する対策が取られていること ・新たなシステム、ソフトウェアを利用するに当たって、利用者たる従業員が適切な計画に基づき、教育研修を受けていること 【出典】金融庁「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）」（令和5年4月7日）
この6項目のうち、実務で証跡が不足しがちなのは3つ目、4つ目、6つ目です。
3つ目：テスト結果の承認がIT部門の管理者だけになっていて、利用部門側の承認が残っていない
4つ目：変更前の内部統制文書が更新されていない。RCMや評価記述書が旧システムのまま放置される
6つ目：利用者教育の計画と実施記録。システム導入時の説明会は行っていても、記録として残していない
運用・管理、安全性、外部委託について
運用・管理については、重要なデータやソフトウェアについて障害や故障等によるデータ消失等に備えて内容を保存し迅速な復旧を図る対策が取られていること、障害や故障等が発生した場合に状況の把握・分析・解決等の対応が適切に行われていることが留意点として挙げられています。
安全性については、データ、システム、ソフトウェア等の不正使用・改竄・破壊等を防止するために、適切なアクセス管理等の方針を定めているかを確認するとされています。
外部委託については、ITに係る業務を外部委託している場合に、企業が適切に外部委託に関する契約の管理を行っているかを検討するとされています。
パッケージ利用企業ほどITGCの比重が高い
見落とされやすい記述が、上記の直後にあります。実施基準は、販売されているパッケージ・ソフトウェアをそのまま利用するような比較的簡易なシステムを有する企業の場合には、ITGCに重点を置く必要があることに留意するとしています。
「自社開発をしていないから開発統制は軽い」という理解は、ここで逆転します。パッケージをそのまま使う企業では、ITACの多くが製品側の機能に依存するため、設定・権限・変更（パッチ適用やバージョンアップ）の管理、すなわちITGCの側に評価の重心が移るという構造です。IPO準備企業やクラウド会計を中心に据えた組織ほど、この点を先に理解しておく価値があります。
監査人はサンプルを共有できる
実施基準は、反復継続的に発生する定型的な取引について経営者が無作為にサンプルを抽出しているような場合、監査人自らが同じ方法で別のサンプルを選択することは効率的でないため、経営者が抽出したサンプルの妥当性を検討したうえで、監査人自らが改めて当該サンプルをサンプルの全部または一部として選択することができるとしています。経営者が行った評価結果についても、評価方法等の妥当性を検証し、作業結果の一部を検証したうえで、監査証拠として利用できるとされています。
実務Tips：この記述を知っていると、サンプル抽出の方法と抽出根拠を監査人と事前に揃えておく価値が明確になります。抽出方法が説明できない状態だと、監査人が別途サンプルを選び、現場は同じ証跡を2回集めることになります。これが「監査法人とのやり取りが増える」典型的な原因の一つです。
監査法人との協議で論点が噛み合わない、指摘の背景が読み切れないという場合は、実施基準の監査人側の記述に立ち返ると整理が早くなります。X-Regulationでは、監査上のリスクの着眼点を踏まえたIT統制の構築・評価をご支援しています。 ▶ J-SOX IT対応支援｜無料相談
8. 評価の効率化——ローテーションの適用
ITGCのローテーション
ITGCの運用状況の評価については、次の取扱いが認められています。
（注）ＩＴ全般統制の項目（財務報告の信頼性に特に重要な影響を及ぼす項目を除く。）のうち、前年度の評価結果が有効であり、かつ、前年度の整備状況と重要な変更がない項目については、その旨を記録することで、前年度の運用状況の評価結果を継続して利用することができる。これにより、ＩＴに係る全般統制の運用状況の評価について、一定の複数会計期間内に一度の頻度で実施されることがある。この取扱いについては、経営者において、ＩＴ環境の変化を踏まえて慎重に判断され、必要に応じて監査人と協議して行われるべきものであり、特定の年数を機械的に適用すべきものではないことに留意する。【出典】金融庁「財務報告に係る内部統制の評価及び監査の基準・実施基準（抄）新旧対照表」（令和5年4月7日）
この取扱いを使う際の要件を分解すると、次のとおりです。
要件 | 内容 |
対象から除かれる項目 | 財務報告の信頼性に特に重要な影響を及ぼす項目 |
条件1 | 前年度の評価結果が有効である |
条件2 | 前年度の整備状況と重要な変更がない |
手続要件 | その旨を記録する |
判断の制約 | IT環境の変化を踏まえて慎重に判断。必要に応じて監査人と協議 |
禁止事項 | 特定の年数を機械的に適用すること |
2023年改訂で追加されたのは、下2行です。改訂前は「実施されることがあることに留意する」で止まっていました。「ITGCは3年に1回でよい」という社内理解は、改訂後の実施基準の記述と整合しません。年数を先に決めるのではなく、対象項目を絞り、条件充足を毎期判定し、記録を残すという順序になります。
自動化されたITACの過年度評価結果の利用
自動化されたITACについては、次の条件をすべて満たす場合に、その結果を記録することで過年度の評価結果を継続利用できます。
過年度に内部統制の不備が発見されずに有効に運用されていると評価された
評価された時点から内部統制が変更されていない
障害・エラー等の不具合が発生していない
関連するITGCの整備・運用状況を確認・評価した結果、ITGCが有効に機能していると判断できる
4つ目にITGCの有効性が入っている点が重要です。第2章で述べたとおり、ITGCが有効であることはITACの有効性を意味しませんが、ITACの評価を軽くするための前提条件としては機能します。追補版は、この考え方に基づく運用テストの方針として、ITGCが有効に機能していると判断できる場合にはIT業務処理統制ごとに1つのアプリケーションを検証し、上記の条件に適合していることを記録して前年度の評価結果を継続利用する、という整理を示しています。
サンプル件数の考え方
実施基準は、日常反復継続する取引について、統計上の二項分布を前提とすると、90%の信頼度を得るには統制上の要点ごとに少なくとも25件のサンプルが必要になるとしています。
追補版は、全社的な内部統制が適切である場合の目安として、頻度別のサンプル件数の例を示しています。
実施の頻度 | サンプル件数 |
1日につき多数 | 25 |
日次 | 25 |
週次 | 5 |
月次 | 2 |
四半期次 | 2 |
年次 | 1 |
なお追補版は、この表のサンプル件数と許容逸脱件数の組合せについて、1日につき多数および日次の場合以外は統計的方法によるものではないと明記しています。週次以下の件数は実務上の目安であって、統計的な裏付けがある数値ではないという理解が必要です。
また、ITを利用して自動化された内部統制については、整備状況が有効と評価された場合、ITGCの有効性を前提に、人手による内部統制よりもサンプル件数を減らし、サンプルの対象期間を短くするなど、運用状況の評価作業を減らすことができるとされています。
落とし穴：許容逸脱件数はいずれも0件です。25件中1件の逸脱で有効と結論づけるには、逸脱の原因分析と、それが例外的事象であることの説明、追加テストの結果という3点セットが必要になります。サンプル件数を絞ることと、逸脱が出たときの対応工数はトレードオフです。
ローテーション判定フローチャート
9. 新しい開発・利用形態への対応
2024年12月に改訂された追補版には、旧版（2007年）にはなかった論点がコラムとして加えられています。
アジャイル／スパイラル開発
追補版は、ウォーターフォール方式では「ユーザ要求・仕様の受付」「開発」「レビュー」「テスト」「本番適用」の各フェーズの区分を付けやすく、その都度確認・承認の手続を組み込みやすいが、アジャイル方式ではこれらのフェーズがスプリントの中に組み込まれて進むため、確認・承認の手続を意識的に設定し、バックログやスプリントレトロスペクティブでの記録などのエビデンスの保存も必要になるとしています。
具体的に監査証拠となりうる記録として挙げられているのは次のとおりです。
ガバナンスレベル：アジャイル開発手法を採用することについての経営層での承認記録
ユーザの要求仕様をどの時点でどのように要件定義にしたかに関するバックログ等
スプリントにおける、UAT（ユーザ受入テスト）に代わるユーザと開発者の合意に関する記録
本番適用についての責任・意思決定に関する明示的な記録
開発チームから運用・保守チームへの成果物の移行の明示的な記録
運用・保守のためのドキュメント
実務Tips：アジャイル開発を採用している組織で最も抜けやすいのは、1つ目と4つ目です。開発手法の採用そのものを経営層が承認した記録と、本番適用の意思決定を誰が行ったかの記録は、開発ツール上の履歴だけでは代替しにくいため、意識して残す必要があります。
ノーコード開発・RPA・EUC
追補版は、ITスキルが高くないスタッフでもRPAなどの自動処理ツールでシステム化を推進できるようになった結果、情報システム部門の管理外でのシステム化が広まると、ツールの引き継ぎやセキュリティ対策が困難になるリスクがあると指摘しています。対応として、情報システム部門がすべてのツールを把握し、適宜テストやモニタリングに関与し、ツール使用のドキュメント化を推進すること、現場や経理部門のスタッフと情報システム部門の連携を強化し、ツール開発に関するガイドラインを策定することを挙げています。
着手の順序：規程を作る前に棚卸です。財務報告に効いているEUC・RPAの一覧（何を、誰が作り、誰が使い、どの数値に影響するか）は、監査人より現場のほうが早く作れます。
生成AI・AIの利用
追補版は、業務プロセスにAIを利用する場合には、AIの特性として出力がブラックボックスで生成されることを踏まえて、プロセス中に適切な出力の正確性・妥当性などのチェック・承認を組み込むことが必要であるとしています。
財務報告に係る内部統制の文脈では、AIの内部構造を統制するのではなく、出力に対する人手のチェックと承認を統制として設計するという整理になります。
スプレッドシート等
追補版は、スプレッドシート等について、実務担当者が自ら利用でき、ITGC等で定められている開発の手順や記録を残さずに利用することが可能であるため、財務報告の作成に関わる場合はその信頼性に関するリスクを検討する必要があるとし、次の対策を挙げています。
表や数式の作成者と利用者を区分するか、第三者が検証する体制を整備する
プログラムの内容を文書化する
関連するデータを定期的にバックアップする
担当者以外が財務報告のデータにアクセスして内容を変更できない体制を整備する
処理結果について、再計算等の検証を検討する
10. ITGCの不備は、どこから「開示すべき重要な不備」になるのか
経営者側の記述
実施基準は、経営者による有効性の判断について次のように述べています。ITGCに不備がある場合には、代替的または補完的な他の内部統制により財務報告の信頼性という目的が達成されているかを検討する。そして、ITGCの不備は財務報告の重要な事項に虚偽記載が発生するリスクに直接に繋がるものではないため、直ちに開示すべき重要な不備と評価されるものではないです。ただし、ITACが有効に機能するよう整備されていても、その有効な運用を継続的に維持できない可能性があり、虚偽記載が発生するリスクが高まることになる、という構成です。
監査人側の記述
同じ論点について、監査人側の記述はもう一段踏み込んでいます。
しかしながら、ＩＴに係る全般統制の不備は、それ自体が財務報告の重要な事項に虚偽記載が発生するリスクに必ずしも直接に繋がるものではないため、業務処理統制が現に有効に機能していることが検証できているのであれば、全般統制の不備をもって直ちに開示すべき重要な不備と評価されるものではないことに留意する。 【出典】金融庁「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）」（令和5年4月7日）
「業務処理統制が現に有効に機能していることが検証できているのであれば」という条件節が加わっている点が実務上の要点です。ITGCの不備が指摘された場合、影響を受けるITACが現に有効に機能していることを示せるかどうかが、その後の評価を分けます。
つながらない例・つながる例
追補版は、両方向の具体例を示しています。
開示すべき重要な不備につながらない場合の例：システム変更に関する文書化が十分でなくても、プログラム受入テストと同等な機能テストを実施してITACが有効に機能していることが確認されていれば、不備とみなさなくてもよい場合がある。
つながる場合の例：各アプリケーション・システムでITACが機能していても、ファイルへのアクセス管理が不十分な場合には、データが改ざんされる可能性がある。このような場合には、容易にデータが改ざんされないような対策を追加するなど、ITGCを有効に機能させる必要がある。
この2例の違いは明快です。文書化の不備は代替的な検証で埋められる余地があるが、アクセス管理の不備は埋められない。データを直接書き換えられる状態は、上位のITACが何であっても打ち消せないためです。是正の優先順位を決める際の基本原則になります。
重要性の判断
不備が開示すべき重要な不備に該当するかは、金額的な面と質的な面の双方から判断します。金額的重要性については、連結総資産・連結売上高・連結税引前利益などに対する比率で判断し、実施基準は連結税引前利益についておおむね5%程度とすることが考えられるとしています。ただしこれらの比率は画一的に適用するのではなく、会社の業種・規模・特性など会社の状況に応じて適切に用いる必要があるとされています。
また、不備が複数存在する場合には、同じ勘定科目に関係する不備をすべて合わせて判断し、勘定科目ごとには重要でなくても複数の勘定科目に係る影響を合わせると重要な虚偽記載に該当する場合には、開示すべき重要な不備となります。
評価範囲外で不備が識別された場合
2023年改訂で追加された論点です。評価範囲外の事業拠点または業務プロセスにおいて開示すべき重要な不備が識別された場合には、当該事業拠点または業務プロセスについては、少なくとも当該開示すべき重要な不備が識別された時点を含む会計期間の評価範囲に含めることが適切であるとされました。
範囲外で不備が見つかったときに「範囲外だから」で処理できなくなったということです。第3章で述べたIT基盤の範囲の切り方が、この論点と直結します。
不備から開示すべき重要な不備に至る判定経路
11. 誰が評価するのか——3線モデルとITGC
実施基準に3線モデルが明記された
2023年改訂で、実施基準に「内部統制とガバナンス及び全組織的なリスク管理」の節が新設され、体制整備の考え方として3線モデルが例示されました。第1線を業務部門内での日常的モニタリングを通じたリスク管理、第2線をリスク管理部門などによる部門横断的なリスク管理、第3線を内部監査部門による独立的評価とし、組織内の権限と責任を明確化しつつ、これらの機能を取締役会または監査役等による監督・監視と適切に連携させることが重要とされています。
ITGCに当てはめると
線 | 担い手 | ITGCにおける役割 |
第1線 | IT部門・利用部門 | 統制の実施と自己点検（ID棚卸、変更管理の記録、ログレビュー） |
第2線 | リスク管理部門 | 方針・規程の整備、部門横断でのモニタリング、評価の取りまとめ |
第3線 | 内部監査部門 | 独立的評価 |
落とし穴：情シスが設計した統制を情シスが評価している
実施基準は、経営者を補助して評価を実施する部署・機関およびその要員について、評価の対象となる業務から独立し、客観性を保つことが求められるとしています。あわせて、日常の業務を遂行する者または業務を執行する部署自身による内部統制の自己点検は、それのみでは独立的評価とは認められないとしています。
追補版はさらに明確で、独立的評価として行われるIT統制に関する内部監査は、IT部門以外の部門によって実施されるとしています。
ただし、実施基準は自己点検を否定していません。自己点検は内部統制の整備・運用状況の改善には有効であり、独立的評価を有効に機能させることにもつながるとされ、自己点検の実施結果に対して独立したモニタリングを適切に実施することにより、内部統制の評価における判断の基礎として自己点検を利用することが考えられるとされています。
設計としては、次の形が実施基準の記述と整合します。
第1線（IT部門）が自己点検を実施し、結果を記録する
第2線または第3線が、その自己点検の結果に対して独立したモニタリングを行う
独立したモニタリングの結果を、評価の判断の基礎として利用する
「情シスの自己点検を、内部統制部門が承認印を押して評価とする」運用は、2の実質がないため、独立性の観点で説明が難しくなります。
内部監査部門にIT知見がない場合
実施基準は、経営者が財務報告に係る内部統制の評価作業の一部を社外の専門家を利用して実施できるとし、その際の留意点として次を挙げています。専門家が単に業務の専門的知識のみならず、内部統制の評価について経営者の依頼内容を達成するのに必要な知識と経験を有していること。評価手続の具体的内容、評価対象期間、評価範囲、サンプル件数等の基本的要件を明確にすること。報告に盛り込まれるべき事項を明確にすること。業務の進捗状況を定期的に検証すること。業務結果が依頼した基本的内容を満たしているか確認すること。
専門家を使う場合でも、評価結果の最終的な責任は経営者が負うという前提が明記されています。丸投げは制度上成立しません。
なお追補版は、独立的評価においてITを利用する技法として、CAAT（Computer-Assisted Audit Techniques：コンピュータ支援監査技法）の利用も考えられるとしています。
12. 費用と工数
公表された相場は存在しない
ITGCの構築・評価に要する費用について、公的機関が公表している相場や標準単価はありません。金額を確定的に示す資料は、一次情報としては存在しないという前提でご覧ください。以下は、見積りの構造を分解したものです。
工数を決める5つの変動要因
1. 評価単位（IT基盤）の数 最も効く要因です。ITGCは基盤単位で評価するため、単位が2つから4つに増えれば、開発・運用・アクセス・委託の4領域すべてが2倍になります。第3章で述べた「単位の切り方」が、そのまま見積りの前提になります。
2. 拠点・子会社数と、それぞれのIT環境の分散度 グループ内で同一の方針・手続に基づいてITが運用されていれば、追補版が述べるとおり、ITGCを共通する1つの基盤に対する統制とみなして評価することで作業の効率化が期待できます。逆に、子会社が個別最適でシステムを導入してきた組織では、単位が増え、質問書の回収と突合に時間がかかります。
3. 外部委託先の数と、SOC1レポートの入手可否 保証報告書を入手できる委託先は、モニタリングの工数が小さくなります。入手できない場合は、質問書・確認書または往査が必要になり、加えて代替統制の設計も生じます。
4. 財務報告に効いているスプレッドシート・EUC・RPAの数 ここが未把握の組織では、棚卸そのものに相応の時間がかかります。初年度の工数が読みにくくなる最大の要因です。
5. 既存の証跡整備水準 規程の有無ではなく、運用の記録が残っているかです。承認記録、テスト結果、ID棚卸の履歴、リストアテストの記録。これらが揃っていれば評価は進み、揃っていなければ整備からやり直しになります。
初年度と2年目以降で、工数の重心が移る
重心 | 主な作業 | |
初年度 | 範囲確定と文書化 | IT基盤の把握、評価単位の決定、監査人との協議、RCM・評価記述書の作成、ギャップの是正 |
2年目以降 | 運用証跡の維持 | 運用状況の評価、変更のあった箇所の再評価、ローテーション対象の条件充足の記録、不備のフォローアップ |
一般的には、初年度の負荷が突出し、2年目以降は運用に移行します。ただし基幹システムの更改やクラウド移行がある年度は、変更管理と移行データの検証で初年度に近い負荷が戻ります。システム更改の計画とJ-SOX評価の計画は、同じカレンダー上で管理してください。
内部工数の分解フレーム
見積りを社内で説明する際は、次の6区分に分けると議論が具体化します。
範囲確定（IT基盤の把握、評価単位の決定、監査人との協議）
リスク評価とRCM作成
整備状況の評価
運用状況の評価（サンプル抽出と証跡収集）
不備の是正とフォローアップ
監査対応
このうち4と6は、証跡の整備水準と、監査人とのサンプル抽出方法の事前合意で大きく変わります（第7章参照）。
どこまで自社で持つかを決める
工数の総量を減らす方法は限られていますが、どこを自社で持ち、どこから外に出すかは設計できます。選択肢は概ね次の3つに整理されます。
形態 | 向いている状況 |
アウトソース | 内部リソースが確保できない。整備・運用や経営者評価の必要な部分を外部が代行する |
コソース | 自社に担当者はいるが経験が不足している。協働しながら進め、ノウハウを内部に残す |
アドバイザリー | 実務は自社で回せる。範囲の切り方、監査人との協議、不備の是正方針など判断を要する部分だけ助言を受ける |
初年度に範囲確定と文書化を外部と進め、2年目以降は運用を内部で回してアドバイザリーに切り替える、という移行も現実的です。判断すべきは「外注するか否か」ではなく、「どのフェーズのどの作業を外に出すか」です。
※本節の費用・工数は、公表資料がないため相場としての金額は示していません。一般的な傾向と変動要因の整理としてご覧ください。
コスト構成の分解図
いかがでしょうか。今回は、J-SOXにおけるIT統制（主にITGC）について知るべき基礎の全てをご紹介しました。
本サイトでは、J-SOX対応における疑問・質問はどんな内容でも受け付けております。その他、制度理解や対応に役立つコンテンツをどんどん配信しているので、是非チェックしてみてください！
執筆者
得田 健人
株式会社 X-Regulation 取締役
大手監査法人において、金融機関から製造業まで多種多様な業種に対する財務諸表監査からJ-SOX監査等を多数経験
