「IT全般統制って何から手をつければいいの？」「監査で指摘されたらどうしよう…」そんなお悩みを抱えていませんか。内部統制、特にJ-SOX法への対応において、IT全般統制（ITGC）は避けて通れない重要なテーマです。しかし、その範囲は広く、専門用語も多いため、担当者の方は大きな負担を感じているかもしれません。本記事では、IT全般統制の基本から、すぐに使える詳細なチェックリスト、評価のポイントまで、あなたの疑問や不安を解消します。
IT全般統制（ITGC）とは？まずはおさらい
IT全般統制のチェックリストを活用する前に、まずはその基本的な概念を理解しておくことが重要です。ここでは、IT全般統制の目的や内部統制における位置づけについて、分かりやすく解説します。
本章では、以下の内容について解説します。
- IT全般統制の目的と重要性
- 内部統制におけるIT全般統制の位置づけ
- IT業務処理統制（ITAC）との違い
IT全般統制の目的と重要性
IT全般統制（ITGC: Information Technology General Controls）とは、企業のITシステム全体が、信頼性を保ちながら正しく機能するためのルールや仕組みのことを指します。 多くの企業では、会計処理や販売管理など、事業の根幹をなす業務をITシステムに依存しています。もし、このITシステムに不備があれば、誤った財務情報が作成されたり、情報漏洩が発生したりと、企業経営に深刻な影響を及ぼしかねません。
IT全般統制の主な目的は、こうしたリスクを管理し、ITシステムを利用して行われる業務処理（IT業務処理統制）が正しく機能する環境を保証することです。 具体的には、システムの開発や変更、日々の運用、アクセス管理などが、定められたルール通りに適切に行われているかを統制します。これにより、財務報告の信頼性を確保し、企業の健全な事業活動を支えることが、IT全般統制の重要な役割なのです。
内部統制におけるIT全般統制の位置づけ
企業の内部統制は、大きく分けて「全社的な内部統制」と、業務プロセスに関する「業務処理統制」、そしてそれらを支える「IT統制」から構成されます。IT全般統制は、この「IT統制」の中核をなす要素の一つです。
IT統制はさらに、「IT全社統制」「IT全般統制」「IT業務処理統制」の3つに分類されます。
- IT全社統制: 経営層がIT戦略や方針を定め、IT統制の基盤を整備すること。
- IT全般統制（ITGC）: IT業務処理統制が有効に機能する環境を保証するための統制。本記事のメイントピックです。
- IT業務処理統制（ITAC）: 個々の業務プロセスに組み込まれたITシステムが、自動的に処理を行う中で不正や誤りを防ぐ統制。
例えるなら、IT全般統制は家全体のセキュリティシステムのようなものです。個々の部屋（業務処理）の鍵がしっかりしていても、家の玄関の鍵が壊れていたり、警備システムが作動していなかったりすれば、家全体の安全は保てません。IT全般統制は、この家全体の安全を確保する役割を担っているのです。
IT業務処理統制（ITAC）との違い
IT全般統制（ITGC）とよく比較されるのが、IT業務処理統制（ITAC: IT Application Controls）です。この二つの違いを理解することは、IT統制の全体像を把握する上で非常に重要です。
IT全般統制（ITGC）が、ITシステムという「環境」全体を対象とするのに対し、IT業務処理統制（ITAC）は、その環境の上で動く個別の「業務処理」を対象とします。
具体例を挙げましょう。
- IT全般統制の例:
- 会計システムへのアクセスは経理部員のみに制限する（アクセス管理）
- システムのプログラムを変更する際は、必ず上長の承認を得て、テストを実施する（変更管理）
- IT業務処理統制の例:
- 請求書データ入力時に、合計金額が自動で計算される（入力情報の完全性・正確性の確保）
- 一定金額以上の取引は、システム上で自動的に上長の承認待ちとなる（承認プロセスの自動化）
このように、IT全般統制はIT業務処理統制が正しく機能するための前提条件となります。 IT全般統制に不備があると、いくら優れたIT業務処理統制を導入しても、その効果が損なわれてしまう可能性があるのです。
【今すぐ使える】IT全般統制のチェックリストテンプレート
お待たせしました。ここでは、J-SOX対応や内部監査ですぐに活用できるIT全般統制のチェックリストをテンプレート形式でご紹介します。金融庁や経済産業省の示す基準に基づき、一般的に評価が必要とされる4つの構成要素に分けて作成しました。 自社の状況に合わせてカスタマイズしてご活用ください。
1. システムの開発・保守に係る管理
システムの新規開発や既存システムの変更が、承認された手続きに従って適切に行われているかを確認します。
| 大項目 | チェック項目（統制の要点） | 確認する証憑（例） |
|---|---|---|
| 開発・保守手続の策定 | システム開発・保守に関する規程やマニュアルが整備され、周知されているか。 | ・システム開発管理規程 ・システム保守管理規程 |
| 要件定義 | 開発・変更の目的や要件が明確に定義され、利用者部門と開発部門で合意形成がなされているか。 | ・要件定義書 ・議事録 |
| 設計・開発 | 承認された要件定義に基づき、設計・開発が行われているか。 | ・設計書 ・プログラムソースコード |
| 変更管理 | プログラムや設定の変更は、申請・承認プロセスを経て行われているか。緊急変更時の手続きも定められているか。 | ・変更管理票（申請書・承認記録） ・変更履歴 |
| テスト | 変更内容が本番環境に影響を与えないよう、テスト計画に基づき十分なテストが実施され、結果が承認されているか。 | ・テスト計画書 ・テスト仕様書、結果報告書 ・承認記録 |
| 本番移行 | 本番環境への移行は、承認された計画・手順に基づき、権限のある担当者のみが実施しているか。 | ・移行計画書、手順書 ・移行作業報告書 ・承認記録 |
2. システムの運用・管理
システムが安定して稼働し、障害発生時に迅速に対応できる体制が整っているかを確認します。
| 大項目 | チェック項目（統制の要点） | 確認する証憑（例） |
|---|---|---|
| 運用手続の策定 | システムの運用に関する規程や操作マニュアルが整備され、周知されているか。 | ・システム運用管理規程 ・オペレーションマニュアル |
| ジョブ管理 | バッチ処理などの定型業務が、スケジュール通りに実行されているか。実行結果は確認されているか。 | ・ジョブスケジュール表 ・ジョブ実行ログ、結果報告書 |
| バックアップ・復旧 | 重要なデータやプログラムは定期的にバックアップが取得されているか。復旧テストは実施されているか。 | ・バックアップ計画書 ・バックアップ取得ログ ・リストアテスト報告書 |
| 障害管理 | システム障害発生時の報告、原因究明、復旧、再発防止策の策定といったプロセスが定められ、実施されているか。 | ・障害管理票（発生報告、対応記録） ・インシデント管理台帳 |
3. 内外からのアクセス管理などシステムの安全性の確保
情報資産を不正なアクセスやサイバー攻撃から守るための物理的・論理的な安全管理策が講じられているかを確認します。
| 大項目 | チェック項目（統制の要点） | 確認する証憑（例） |
|---|---|---|
| 情報セキュリティ方針 | 情報セキュリティに関する基本方針や関連規程が整備され、全従業員に周知・教育されているか。 | ・情報セキュリティポリシー ・研修の実施記録 |
| ID・パスワード管理 | IDの登録・変更・削除は申請・承認に基づき行われているか。パスワードポリシー（文字数、有効期限等）は適切に設定・運用されているか。 | ・ID管理台帳 ・ID発行/変更/削除申請書 ・パスワードポリシー設定画面 |
| アクセス権限管理 | 職務分掌に基づき、業務上必要な最小限のアクセス権限が付与されているか。定期的な棚卸しは実施されているか。 | ・アクセス権限申請書 ・アクセス権限一覧表 ・棚卸しの実施記録 |
| 特権IDの管理 | システム管理者などの特権IDは、厳格に管理・制限され、その利用は承認・記録されているか。 | ・特権ID管理台帳 ・特権ID利用申請書、承認記録 ・操作ログ |
| ログ管理 | 重要なシステムへのアクセスログや操作ログが取得・保管され、定期的にモニタリングされているか。 | ・ログ管理規程 ・ログデータ ・モニタリング記録 |
| 物理的セキュリティ | サーバールームなど重要な設備への入退室管理は適切に行われているか。 | ・入退室管理記録 |
4. 外部委託に関する契約の管理
システムの開発や運用を外部に委託している場合に、委託先が適切に業務を遂行し、情報セキュリティを維持しているかを確認します。
| 大項目 | チェック項目（統制の要点） | 確認する証憑（例） |
|---|---|---|
| 委託先の選定 | 外部委託先の選定基準が定められ、評価に基づき選定されているか。 | ・委託先選定規程 ・委託先評価シート |
| 契約管理 | 委託する業務の範囲、責任分担、機密保持義務などを明記した契約を締結しているか。 | ・業務委託契約書 ・機密保持契約書（NDA） |
| 委託先の監督・評価 | 委託先の業務遂行状況やセキュリティ対策状況を、定期的にモニタリング・評価しているか。 | ・委託先からの業務報告書 ・監査報告書（SOCレポート等） ・定例会議事録 |
IT全般統制チェックリスト【4つの構成要素】評価のポイント
チェックリストをただ埋めるだけでは、有効な統制は実現できません。各項目を評価する際に、どのような点に着目すべきか、具体的なポイントを解説します。これにより、形式的ではない、実質的なIT全般統制の評価が可能になります。
本章では、以下の4つの構成要素ごとの評価ポイントを解説します。
- システムの開発・保守に係る管理
- システムの運用・管理
- 内外からのアクセス管理などシステムの安全性の確保
- 外部委託に関する契約の管理
システムの開発・保守に係る管理
ここでの核心は、「勝手な変更」を防ぐ仕組みが機能しているかという点です。システムの変更は、業務への影響が大きいため、慎重に行われなければなりません。評価の際は、変更管理プロセスが実際に遵守されているかを重点的に確認しましょう。
例えば、「変更管理票」をサンプル抽出し、申請者、承認者、作業者が適切に分離されているか（職務分掌）、承認のない変更が行われていないかを確認します。また、テストが形式的に行われるだけでなく、利用者部門が関与し、変更内容が要件を満たしていることを確認しているかも重要なポイントです。 開発環境、テスト環境、本番環境が物理的または論理的に分離され、本番環境へのアクセスが厳しく制限されているかも確認が必要です。
システムの運用・管理
システムの安定稼働を支える運用・管理では、「万が一」への備えが万全かが問われます。特に重要なのが、バックアップと障害管理です。バックアップについては、単に取得しているだけでなく、そのデータから正常にシステムを復旧できるかを確認する「リストアテスト」が定期的に行われているかがポイントです。
障害管理では、障害が発生した際に、その場しのぎの対応で終わっていないかを確認します。障害の記録が適切に残され、根本原因が分析され、恒久的な再発防止策が講じられているかまで追跡することが重要です。ジョブ管理においては、エラーが発生した際の検知・通知・対応のプロセスが明確になっているかを確認しましょう。
内外からのアクセス管理などシステムの安全性の確保
情報セキュリティの要であるこの領域では、「誰が、何に、どこまでアクセスできるのか」が適切に管理されているかが最大のポイントです。特に、IDとアクセス権限の管理は監査でも厳しく見られる項目です。
評価の際は、入社・異動・退職に合わせたIDの棚卸しがタイムリーに行われているかを確認します。退職者のIDが残ったままになっているケースは、重大な不備と見なされます。「業務上、必要最小限の権限（ミニマム権限）の原則」が守られているか、定期的にアクセス権限の見直し（棚卸し）が行われているかも確認しましょう。 また、全ての操作が可能な「特権ID」については、誰が、いつ、何のために使用したのか、その記録と承認のプロセスが厳格に運用されているかを徹底的にチェックする必要があります。
外部委託に関する契約の管理
システムの開発や運用を外部に委託することは、業務効率化の有効な手段ですが、同時に統制の目が届きにくくなるリスクもはらみます。 ここでのポイントは、「委託先に丸投げ」になっていないかです。
契約書に、委託業務の範囲や納品物の品質基準、セキュリティ対策に関する義務などが具体的に明記されているかを確認します。その上で、委託先が契約通りに業務を遂行しているかをモニタリングする仕組みが重要になります。 定期的な報告会の実施や、委託先から内部統制に関する報告書（SOCレポートなど）を入手し、内容を評価しているかを確認しましょう。委託先に重要なデータを預ける場合は、その管理体制についても十分に確認し、リスクを評価しておく必要があります。
IT全般統制の評価でよくある不備と対策
IT全般統制の整備・運用において、多くの企業が陥りがちな「よくある不備」が存在します。ここでは、代表的な不備の事例とその対策について解説します。自社の状況と照らし合わせ、監査で指摘を受ける前に改善しておきましょう。
本章では、以下の不備と対策について解説します。
- アクセス権限管理の不備
- ログの取得・監視の不備
- 変更管理プロセスの形骸化
アクセス権限管理の不備
最も多く見られる不備の一つが、アクセス権限管理の不備です。具体的には、退職者や異動した社員のアカウントが削除されずに残っている、必要以上の権限が与えられているといったケースが挙げられます。これらは内部不正や情報漏洩の温床となり、監査でも重大な指摘事項となり得ます。
対策としては、まずID管理とアクセス権限に関する規程を明確に定めることが第一歩です。その上で、人事情報と連携し、入社・異動・退職時にIDの登録・変更・削除が速やかに行われるワークフローを構築することが重要です。さらに、最低でも半期に一度は、各部署の責任者が部下のアクセス権限が適切であるかを確認する「棚卸し」を実施し、その記録を保管する運用を徹底しましょう。
ログの取得・監視の不備
「ログは取得しているが、誰も見ていない」というのも、よくある不備の典型例です。システムへのログイン履歴や重要なデータの操作履歴などのログは、不正の発見や障害発生時の原因究明に不可欠な情報です。しかし、ログを取得しているだけで満足してしまい、定期的な監視（モニタリング）が行われていないケースが少なくありません。
対策としては、まずどのシステムの、どのような操作のログを取得・保管するのかを定義します。特に、特権IDによる操作ログやデータベースへの直接アクセスログは必須です。その上で、「誰が」「いつ」「どのように」ログをレビューするのか、異常を検知した場合の報告・対応フローを明確に定めます。全てのログを目視で確認するのは非現実的なため、ログ管理ツールを導入し、不審なアクセスの兆候などを自動で検知・通知する仕組みを構築することも有効な対策です。
変更管理プロセスの形骸化
システムの変更管理に関するルールは定めているものの、緊急時や軽微な修正を理由に、申請・承認プロセスが省略されてしまう「形骸化」も深刻な問題です。承認のない変更は、たとえ悪意がなくとも、予期せぬシステム障害やデータの不整合を引き起こす原因となります。
対策としては、いかなる変更も例外なく変更管理プロセスの対象とするという原則を徹底することが重要です。緊急時の対応についても、事後報告で済ませるのではなく、事後速やかに正規の承認手続きを踏むルールを定めます。また、開発担当者と運用担当者が同じであるなど、職務分掌が曖昧な場合に形骸化しやすいため、開発・テスト・本番移行の各段階で担当者や承認者を分離することが、牽制機能を働かせる上で効果的です。
IT全般統制の負担を軽減！効率化の3つのコツ
「IT全般統制の重要性は分かったけれど、対応する人手も時間もない…」というのが多くの担当者の本音ではないでしょうか。ここでは、IT全般統制にかかる負担を軽減し、効率的に運用するための3つのコツをご紹介します。
本章では、以下の効率化のコツについて解説します。
- SaaSやパッケージ製品の活用
- ITサービスマネジメントツールの導入
- 専門家（コンサルティング）への相談
SaaSやパッケージ製品の活用
自社で開発したシステム（スクラッチ開発）は、柔軟性が高い反面、IT全般統制の構築・評価にかかる負担が大きくなる傾向があります。 そこで有効なのが、SaaS（Software as a Service）や実績のあるパッケージソフトウェアの活用です。
多くのSaaSやパッケージ製品は、提供ベンダー側で厳格なセキュリティ管理や運用体制が敷かれています。利用企業は、ベンダーが取得しているSOC（Service Organization Control）レポートなどを入手することで、自社での評価作業の一部を代替でき、監査対応の負担を大幅に軽減することが可能です。 会計システムや人事給与システムなど、定型的な業務には積極的にSaaSやパッケージ製品を導入することを検討しましょう。
ITサービスマネジメントツールの導入
IT全般統制の多くの業務は、申請、承認、記録といった一連のプロセスで構成されています。これらの業務をExcelやメールで手作業管理していると、ミスが発生しやすく、証跡の管理も煩雑になります。そこで役立つのが、ITサービスマネジメント（ITSM）ツールです。
ITSMツールを導入することで、システムの変更管理、インシデント管理、ID管理などのワークフローを自動化できます。 申請から承認までの流れがシステム上で完結し、誰がいつ何を承認したかの記録（ログ）も自動で保存されるため、統制の強化と業務効率化を同時に実現できます。監査の際にも、必要な証跡を迅速に提出できるという大きなメリットがあります。
専門家（コンサルティング）への相談
IT全般統制は専門性が高く、特に初めて対応する企業や、ITに詳しい人材が不足している企業にとっては、自社だけで全てを完結させるのは困難な場合があります。 そのような場合は、無理せず外部の専門家の力を借りることも賢明な選択です。
IT統制を専門とするコンサルティング会社は、豊富な知識と経験に基づき、企業の状況に合わせた最適な統制の仕組みづくりを支援してくれます。 文書作成の支援から、監査法人との協議のサポートまで、幅広いサービスを提供しているため、自社の課題に合わせて活用することで、時間と労力を大幅に節約し、より確実な統制環境を構築することが可能になります。
よくある質問
IT全般統制の評価範囲はどこまでですか？
IT全般統制の評価範囲は、原則として財務報告の信頼性に重要な影響を及ぼす業務プロセスに関連する全てのIT基盤が対象となります。 まず、財務諸表の重要な勘定科目を特定し、その勘定科目に関連する業務プロセスと、そこで利用されているシステムを洗い出します。そして、そのシステムを支えるIT基盤（ハードウェア、OS、ネットワーク、データベースなど）が評価範囲となります。 複数のシステムが共通のIT基盤で運用されている場合は、そのIT基盤を一つの単位として評価します。
IT全般統制に不備があった場合はどうなりますか？
IT全般統制に不備が発見された場合、直ちに内部統制の「重要な欠陥」と判断されるわけではありません。 まず、その不備がIT業務処理統制にどのような影響を与えるかを評価します。もし、不備を補う代替的・補完的な統制（例えば、手作業によるチェックなど）が存在し、それによって財務報告の信頼性が確保されていると判断されれば、重要な欠陥には至らない場合もあります。 しかし、不備が広範囲に影響を及ぼす可能性があり、代替手段もない場合は、改善が求められます。期末までに改善されなければ、「開示すべき重要な不備」として内部統制報告書に記載する必要が出てきます。
IT全般統制の文書化（3点セット）とは何ですか？
IT全般統制の文書化とは、統制の内容を誰が見ても理解できるように記録に残すことです。一般的に、業務プロセスの統制と同様に「3点セット」と呼ばれる文書を作成します。
- 業務記述書: 統制活動の内容を文章で記述したもの。誰が、いつ、何をするのかを具体的に記載します。
- フローチャート: 業務やシステムの処理の流れを、記号を用いて図で表現したもの。全体の流れを視覚的に把握できます。
- リスクコントロールマトリクス（RCM）: 業務に潜むリスクと、そのリスクに対応する統制活動（コントロール）を一覧表形式でまとめたもの。リスクと統制の対応関係が明確になります。
これらの文書を整備することで、統制の状況が可視化され、評価や監査がスムーズに進められるようになります。
中小企業でもIT全般統制は必要ですか？
上場企業およびその連結子会社は、金融商品取引法（J-SOX法）に基づき、内部統制報告書の提出が義務付けられており、IT全般統制の整備・評価は必須です。
一方、非上場の中小企業には法的な義務はありません。しかし、IT全般統制を整備することには、業務の効率化、情報漏洩などのセキュリティリスクの低減、内部不正の防止といった多くのメリットがあります。 企業の信頼性を高め、持続的な成長を目指す上で、IT全般統制の考え方を取り入れることは非常に有益です。将来的にIPO（株式上場）を目指している企業であれば、早期からの準備が不可欠となります。
まとめ
- IT全般統制はITシステム全体の信頼性を確保する仕組みです。
- IT業務処理統制が正しく機能するための土台となります。
- 主な構成要素は「開発・保守」「運用・管理」です。
- 「安全性の確保」「外部委託管理」も重要な要素です。
- チェックリストは4つの構成要素に分けて作成します。
- 開発・保守では「勝手な変更」を防ぐ仕組みが重要です。
- 運用・管理ではバックアップと障害管理がポイントです。
- 安全性の確保ではIDとアクセス権限の管理を徹底します。
- 外部委託では「丸投げ」にせず監督体制を構築します。
- よくある不備はアクセス権限管理の甘さです。
- ログの形骸化や変更管理プロセスの不備も要注意です。
- 効率化にはSaaSやパッケージ製品の活用が有効です。
- ITSMツール導入でワークフローを自動化できます。
- 専門のコンサルティング活用も有効な手段です。
- 企業の信頼性向上と持続的成長に不可欠な取り組みです。
