監査法人との期中打ち合わせで、IT監査の担当者がこう切り出しました。「会計システムのアクセス権の棚卸は確認できました。ではデータベースの管理者権限は、誰が、どう管理していますか」。社内のJ-SOX評価チームは顔を見合わせます。評価してきたのは会計システムの画面上のユーザー一覧だけで、その下にあるデータベースやサーバーは、情報システム部門に任せきりでした。
情報システム部門に確認すると、データベースの管理者IDは保守委託先と共有で使っており、誰がいつ操作したかは追えない状態でした。会計システムの画面上の権限がどれだけ厳格でも、データベースを直接書き換えられる経路があれば、統制は迂回できてしまいます（本記事の事例はすべて架空のモデルケースです）。
IT全般統制（ITGC）の監査で難しいのは、何を「対象」とするかの線引きです。この記事では、対象システムと技術レイヤーを先に固定し、そのうえで5つの領域の項目を当てはめる形のITGC監査チェックリストを公開します。
この記事の要点
- ITGCのチェックリストは、まず「対象システム一覧」でシステムと技術レイヤー（アプリ・DB・OS・ネットワーク）を固定してから、領域別の項目を当てはめます
- 項目は、金融庁の実施基準が例示する4つ（開発・保守、運用・管理、アクセス管理などの安全性確保、外部委託契約の管理）に沿って5領域で構成します
- SaaSやクラウドは、SOC報告書の入手・評価と、利用者側で実施すべき補完統制（CUEC）の確認で扱います
- 過年度の評価結果を継続利用するかどうかは、IT環境の変化を踏まえて判断し、特定の年数を機械的に適用しません
ITGC監査チェックリストとは：なぜ「土台」を先に見るのか
ITGCの定義と4つの例示
IT全般統制（IT General Controls）は、金融庁の「財務報告に係る内部統制の評価及び監査に関する実施基準」で、業務処理統制が有効に機能する環境を保証するための統制活動と説明されています。実施基準は具体例として、システムの開発・保守、システムの運用・管理、内外からのアクセス管理などシステムの安全性の確保、外部委託に関する契約の管理の4つを挙げています。
本テンプレートは、この4つの例示に沿いながら、実務で評価しやすいように「アクセス管理」「変更管理」「運用管理」「システム開発」「外部委託」の5領域に分けています。変更管理と開発を分けたのは、日常的なプログラム変更と、新規導入や大規模更改とでは、統制の担い手も証拠も異なるためです。
なぜITGCを「先に」見るのか
システムに組み込まれた自動統制（ITに係る業務処理統制、ITAC）は、一度正しく設定されれば毎回同じように動きます。そのため、自動統制の運用テストは少ない件数で済むとされています。ただしこれは、プログラムが勝手に変更されていない、権限のない人が設定を変えられない、という前提があって初めて成り立つ理屈です。この前提を支えるのがITGCです。
ITGCに不備があると、そのITGCに依存する自動統制やシステム出力帳票（IPE）の信頼性にも疑問が生じ、追加の手続が必要になります。実施基準も、ITGCが有効でもそれだけでは業務処理統制の有効性を結論づけられない一方、ITGCに不備があれば業務処理統制への影響を検討する必要があるという考え方に立っています。両者の関係はITACとITGCの違いで詳しく解説しています。
2023年改訂で意識すべき点
2023年4月に企業会計審議会が公表した基準・実施基準の改訂（2024年4月1日以後開始する事業年度から適用）では、ITの委託業務に係る統制の重要性や、クラウド・リモートアクセスの活用に伴うサイバーリスクを踏まえた情報システムのセキュリティ確保の重要性が明記されました。また、ITGCの運用評価を一定の複数会計期間に一度とする取扱いについては、IT環境の変化を踏まえて慎重に判断し、必要に応じて監査人と協議すべきで、特定の年数を機械的に適用すべきものではないことが明確化されています。改訂の全体像はJ-SOX改訂のポイントをご覧ください。
いつ使うか・誰が記入するか
使う場面
1つ目は、J-SOXの評価でITGCの整備・運用状況を評価する場面です。2つ目は、内部監査としてシステム監査やIT部門の業務監査を行う場面です。3つ目は、会計システムや販売管理システムの入替え、クラウド移行の前後で、統制が新しい環境に引き継がれたかを確かめる場面です。自社の現状を大まかにつかみたい段階では、先にITGC簡易診断で4領域の弱点を把握し、スコアの低い領域から本テンプレートの項目を深掘りする使い方もできます。
役割分担
| 役割 | 担当する作業 | 記入する欄 |
|---|---|---|
| 監査責任者（主査） | 対象システムとレイヤーの決定、項目の取捨選択 | ヘッダー部、対象システム一覧 |
| IT監査担当者 | 設定・ログ・権限の確認、サンプルテスト | 手続結果、件数、例外、調書番号 |
| 業務プロセス担当者 | 対象システムに依存する自動統制・IPEの特定 | 対象システム一覧の「依存する統制」欄 |
| レビュー担当 | 結論と、業務処理統制への影響評価の確認 | レビュー欄 |
情報システム部門は被監査側として、設定画面・ログ・手順書を提供します。チェックリストへの記入は監査側が行い、質問への回答は調書に記録します。
テンプレート本体①：ヘッダーと対象システム一覧
ヘッダー部
| 項目 | 記入内容 |
|---|---|
| 監査名 | 例：2026年度 IT全般統制評価 |
| 評価基準日／対象期間 | 例：2026年3月31日／2025年4月1日〜2026年3月31日 |
| 準拠する規程・基準 | 情報セキュリティ規程、システム管理規程、変更管理手順書、実施基準、経済産業省「システム管理基準」など（版数） |
| 前年度からの変更 | システムの入替え、クラウド移行、委託先変更、組織変更 |
| 過年度結果の継続利用 | 継続利用する項目と判断理由（IT環境の変化の有無） |
| 作成者／レビュー者 | 氏名・日付 |
対象システム一覧
チェックリストの項目は、この一覧の行ごとに当てはめます。財務報告に関連する自動統制やIPEが依存するシステムを特定し、アプリケーションだけでなく、その下のデータベース・OS・ネットワークのうち、統制を迂回できる経路になりうるレイヤーを含めます。
| システム名 | 用途 | 形態 | 対象レイヤー | 依存する統制・IPE | 運用主体 |
|---|---|---|---|---|---|
| 会計システム | 仕訳・決算 | オンプレミス | アプリ、DB、OS | 自動仕訳、承認ワークフロー、試算表 | 情報システム部＋保守委託先 |
| 販売管理システム | 受注・出荷・請求 | SaaS | アプリ（設定） | 与信チェック、売上計上、売掛金年齢表 | SaaS事業者＋営業管理部 |
| 経費精算システム | 立替精算 | SaaS | アプリ（設定） | 自己承認の禁止、上限チェック | SaaS事業者＋経理部 |
| 共通基盤 | 認証・ネットワーク | オンプレミス | ディレクトリ、ネットワーク | 全システムの認証 | 情報システム部 |
テンプレート本体②：5領域のチェック項目
各項目の右側には、共通の結果記入欄として「対象システム」「実施件数／母集団件数」「例外件数」「結論」「調書番号」「実施者・日付」の列を追加します。
領域A：アクセス管理
| No | チェック項目 | 手続 | 件数の目安 |
|---|---|---|---|
| A-1 | ユーザーIDの付与・変更は申請と承認に基づいている | 期間中の新規・変更IDから抽出し、申請・承認と照合する | 25件または全件 |
| A-2 | 退職者・異動者の権限が規程の期限内に削除・変更されている | 人事の退職・異動データとID一覧・削除日を突合する | 全件（データ） |
| A-3 | 特権ID（管理者権限）が必要最小限の者に限られ、共有IDは個人に紐付けて管理されている | 特権ID一覧を閲覧し、保有者の必要性を確認する | 全件 |
| A-4 | 特権IDの利用ログが取得され、定期的にレビューされている | ログとレビュー記録を閲覧する | レビュー回数の全件または抽出 |
| A-5 | アクセス権の定期棚卸が実施され、不要な権限が削除されている | 棚卸記録と削除の反映を確認する | 棚卸の全回 |
| A-6 | パスワード要件・多要素認証・アカウントロックがシステムで強制されている | 設定画面を閲覧する | システム単位 |
| A-7 | データベースやOSへの直接アクセスが制限され、記録されている | 接続経路と権限、ログを確認する | システム単位 |
| A-8 | 職務分掌上、両立しない権限の組み合わせを持つユーザーがいない | 権限一覧から衝突する組み合わせを抽出する | 全件（データ） |
領域B：変更管理
| No | チェック項目 | 手続 | 件数の目安 |
|---|---|---|---|
| B-1 | プログラム・設定の変更が申請・承認・テスト・本番移行の手順を経ている | 変更一覧から抽出し、各段階の記録を確認する | 25件または全件 |
| B-2 | 本番環境の変更一覧は網羅的である（システムのログ等と照合） | 本番の変更ログと変更管理台帳を突合する | 全件（データ） |
| B-3 | 開発者が本番環境へ直接移行できない（環境と権限の分離） | 本番移行権限の保有者を確認する | システム単位 |
| B-4 | 利用部門によるテスト（受入テスト）の承認が記録されている | テスト記録を閲覧する | B-1のサンプル |
| B-5 | 緊急変更は定められた手続で実施され、事後に承認されている | 緊急変更の全件を確認する | 該当の全件 |
| B-6 | SaaSの設定変更やバージョンアップの影響が評価されている | 事業者の通知と社内の影響評価の記録を確認する | 通知の全件または抽出 |
領域C：運用管理
| No | チェック項目 | 手続 | 件数の目安 |
|---|---|---|---|
| C-1 | バッチ処理・ジョブの実行結果が監視され、異常終了時の対応が記録されている | 異常終了の記録と対応を確認する | 異常の全件 |
| C-2 | ジョブスケジュールの変更が承認されている | スケジュール変更ログを確認する | 変更の全件または抽出 |
| C-3 | バックアップが計画どおり取得され、復元テストが行われている | 取得記録と復元テストの記録を閲覧する | 抽出＋テストの全回 |
| C-4 | 障害・インシデントが記録され、原因分析と再発防止が行われている | インシデント台帳を閲覧する | 重要インシデントの全件 |
| C-5 | 脆弱性情報の収集とパッチ適用が管理されている | パッチ適用記録を確認する | システム単位 |
領域D：システム開発・導入
| No | チェック項目 | 手続 | 件数の目安 |
|---|---|---|---|
| D-1 | 新規導入・大規模更改は、要件定義・設計・テスト・移行の各段階で承認されている | プロジェクトの承認記録を閲覧する | 期間中の全プロジェクト |
| D-2 | データ移行の完全性・正確性が件数・金額の照合などで検証されている | 移行検証の記録を確認する | 移行の全件 |
| D-3 | 自動統制・帳票の設定が要件どおりであることがテストで確認されている | テスト仕様と結果を閲覧する | 財務関連の機能 |
領域E：外部委託
| No | チェック項目 | 手続 | 件数の目安 |
|---|---|---|---|
| E-1 | 委託契約に、セキュリティ要件・報告義務・監査権などが定められている | 契約書を閲覧する | 重要な委託先の全件 |
| E-2 | 委託先のSOC報告書等を入手し、対象期間・範囲・例外事項を評価している | 評価記録を閲覧する | 重要な委託先の全件 |
| E-3 | SOC報告書に記載された利用者側の補完統制（CUEC）を自社で実施している | CUECの対応表と実施記録を確認する | CUECの全項目 |
| E-4 | SOC報告書の対象期間と自社の評価期間のずれを、ブリッジレター等で補っている | ブリッジレター等を閲覧する | 該当の全件 |
記入例：会計システムのITGC評価
架空の会社の会計システム（オンプレミス）を対象にした記入例です。
| No | 実施件数 | 例外件数 | 結論 | 記入内容 |
|---|---|---|---|---|
| A-2 | 退職者 64名（全件） | 1名 | 例外あり | 退職後9日間IDが有効だった者1名。ログ上、退職後のログインなし。人事の退職連絡が月次一括のため（調書 IT-A02） |
| A-3 | DB特権ID 3件（全件） | 1件 | 不備 | DB管理者IDを保守委託先の担当者3名で共有。操作者を特定できない。業務処理統制への影響をプロセス担当と検討中（調書 IT-A03） |
| B-2 | 本番変更ログ 38件（全件） | 2件 | 追加手続へ | 変更管理台帳にない本番変更2件。いずれもDB特権IDによる直接更新（A-3と同一原因）。変更内容を確認中（調書 IT-B02） |
| C-3 | 取得記録 12か月分＋復元テスト 2回 | 0件 | 有効 | 日次バックアップの取得失敗は期間中なし。半期ごとの復元テストで試算表の再現を確認（調書 IT-C03） |
A-3とB-2は同じ原因から生じた例外です。DB特権IDを個人に紐付けられない状態では、変更の実施者も承認の有無も追えないため、業務処理統制への影響を具体的に検討する必要があります。影響の検討では、該当期間に直接更新された財務データを特定し、更新の内容と正当性を確かめる追加手続を行うのが一般的です。不備の評価の進め方はJ-SOXの不備評価で解説しています。
クラウド・SaaSの扱い：SOC報告書とCUEC
「SaaSだから対象外」ではない
SaaSでは、アプリケーションの変更やインフラの運用を事業者が担います。自社で統制を実施できない部分は、事業者が提供するSOC報告書（受託業務に係る内部統制の保証報告書）を入手し、その内容を評価することで確認します。財務報告に関わる統制の評価にはSOC1、セキュリティなどの観点にはSOC2が使われるのが一般的です。
一方、SaaSでも、ユーザーIDの付与・削除、権限設定、業務に関わる設定の変更は利用者である自社の責任です。本テンプレートの領域Aと領域B-6は、SaaSでも自社側の項目として残ります。
SOC報告書を評価するときの記入欄
| 確認項目 | 記入内容の例 |
|---|---|
| 報告書の種類と対象期間 | SOC1 Type2、2025年4月1日〜2026年3月31日 |
| 対象範囲 | 自社が利用するサービス・データセンターが含まれているか |
| 監査人の意見 | 限定事項の有無 |
| 例外事項 | 例外の内容と、自社への影響の検討結果 |
| サブサービス組織 | 除外方式の場合、再委託先の統制をどう確認したか |
| CUEC | 各CUECに対応する自社の統制と、その評価結果 |
| 期間のずれ | ブリッジレターの入手有無 |
SOC報告書の読み方はITGC（IT全般統制）とSOC報告書の見方で詳しく解説しています。
運用のコツ
対象システム一覧を毎年作り直す
ITGCの評価範囲は、財務報告に関連する自動統制とIPEがどのシステムに依存しているかで決まります。業務プロセス側でRCMが更新されたら、対象システム一覧も連動して更新します。一覧の「前年度からの変更」欄が空欄のまま続いているときは、変更がないのか確認していないのかを区別できないので、「変更なし（確認日・確認者）」と書きます。
「全件データ」の項目を増やす
退職者の権限削除（A-2）や本番変更の網羅性（B-2）は、人事データや本番環境のログと突合すれば全件で確認できます。サンプルでは見落としがちな少数の例外を確実に拾えるうえ、翌年以降も同じ手順で繰り返せます。アクセス管理と変更管理の手続の詳細は、アクセス管理の監査と変更管理の監査を参照してください。
サイバーセキュリティの観点を切り分ける
ITGCは財務報告の信頼性を支える統制ですが、2023年の実施基準改訂はセキュリティ確保の重要性にも触れています。また、IIAのトピック別要求事項のうちサイバーセキュリティは2026年2月5日に発効しています。本テンプレートの項目の多くはサイバーセキュリティの監査とも重なるため、どの項目がどの監査目的に使われるかを「用途」列で区別しておくと、同じテストを二度行う無駄を避けられます。詳しくはIIAトピック別要求事項をご覧ください。
よくある記入ミスと対策
ミス1：アプリケーション層だけを見る
画面上のユーザー一覧だけを確認し、データベースやOSの特権IDを見ないと、冒頭の事例のような迂回経路が残ります。対象システム一覧で、どのレイヤーまで評価するかと、その理由を先に決めて記入します。
ミス2：変更一覧の網羅性を確かめない
変更管理台帳から25件を抜いてすべて承認済みだったとしても、台帳に載らない変更があれば結論は変わります。サンプルを抜く前に、本番環境のログと台帳を突合する項目（B-2）を実施します。
ミス3：SOC報告書を「入手済み」で終える
報告書のファイルを保存しただけでは評価になりません。対象範囲、例外事項、CUECへの対応、期間のずれを記入欄に沿って確認し、結論を書きます。
ミス4：ITGCの例外を業務処理統制に結び付けない
ITGCの例外を見つけたら、その例外がどの自動統制やIPEに影響するかを、対象システム一覧の「依存する統制」欄から特定します。ITGC単独で結論を閉じてしまうと、財務報告への影響の検討が抜け落ちます。
よくある質問
ITGCの評価は毎年すべての項目で必要ですか？
実施基準は、前年度の評価結果が有効で、整備状況に重要な変更がない項目について、その旨を記録することで前年度の結果を継続利用できるとし、一定の複数会計期間内に一度の頻度で運用評価を行う方法もあるとしています。ただし、その判断はIT環境の変化を踏まえて慎重に行い、必要に応じて監査人と協議します。ヘッダー部の「過年度結果の継続利用」欄に判断理由を残してください。
中小規模の会社で、IT部門が1〜2名しかいない場合はどうしますか？
開発と本番移行の職務分離が難しい場合は、移行後に第三者（IT部門外の管理者など）が変更ログをレビューするといった発見的な統制で補う方法があります。チェックリストには、分離できない理由と代替統制を記入し、その有効性をテストします。
経済産業省のシステム管理基準とは、どう使い分ければよいですか？
J-SOXのITGC評価は、財務報告の信頼性に関わる統制に焦点を当てます。システム管理基準は、ITガバナンスとITマネジメント全般の判断尺度で、より広い範囲をカバーします。内部監査でシステム監査を行う場合は、本テンプレートを出発点に、システム管理基準の項目で範囲を広げる使い方ができます。詳しくは経済産業省のシステム監査基準・システム管理基準をご覧ください。
まとめ
ITGCのチェックリストは、対象システムとレイヤーを先に固定することで初めて「何を評価したか」を説明できる様式になります。本記事のテンプレートは、対象システム一覧と、アクセス管理・変更管理・運用管理・システム開発・外部委託の5領域の項目で構成しています。まずはITGC簡易診断で弱い領域を把握し、対象システム一覧を1枚作るところから始めてみてください。
あわせて【テンプレート】監査調書様式、【テンプレート】購買業務監査チェックリストも参考にしてください。
ITGCの評価設計や対象システムの整理についてのご相談は、お問い合わせからお寄せください。
参考資料
- 金融庁 企業会計審議会「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）」（2023年4月7日） https://www.fsa.go.jp/news/r4/sonota/20230407/20230407.html
- 経済産業省「システム監査基準」「システム管理基準」（2023年4月改訂）
- 日本公認会計士協会「財務報告内部統制監査基準報告書第1号『財務報告に係る内部統制の監査』の改正」 https://jicpa.or.jp/specialized_field/20230804efg.html
- 内部監査人協会（IIA）「Topical Requirements」（Cybersecurity ほか） https://www.theiia.org/
- NIST SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
