コトラ（広報チーム） 
IT全般統制は、財務報告に関わるシステムを安全かつ安定的に利用するための基盤となる仕組みです。上場企業では、金融商品取引法に基づく内部統制報告制度、いわゆるJ-SOXへの対応において重要な位置づけとなります。
会計システムだけでなく、販売管理、購買管理、在庫管理、給与計算、連結決算などのシステムが財務数値に影響する場合、適切なアクセス管理や変更管理、運用管理が求められます。本記事では、IT全般統制の目的、対象範囲、実務で押さえるべき管理領域と構築手順を解説します。
IT全般統制（ITGC）とは
IT全般統制の定義
IT全般統制とは、業務システムに組み込まれた自動的なチェック機能や処理が、継続して正しく機能するための環境を整える統制です。英語ではIT General Controlsと呼ばれ、ITGCと略されます。
対象となるのは、個別の業務処理ではなく、システムを支える共通的な管理の仕組みです。たとえば、利用者のアカウント管理、プログラム変更時の承認とテスト、バックアップ、障害対応、外部委託先の管理などが該当します。
J-SOXにおけるIT全般統制の位置づけ
J-SOXは、上場企業などが財務報告に係る内部統制を整備・運用し、その有効性を経営者が評価して報告する制度です。IT全般統制は、この財務報告の信頼性を支えるIT統制の一つです。
金融庁の実施基準では、ITに関する統制を大きく全般統制と業務処理統制に整理しています。IT全般統制は、業務処理統制が有効に機能するための前提を整える役割を持ちます。
IT全般統制が必要とされる目的
IT全般統制の目的は、財務情報に影響するシステムとデータの信頼性を確保することです。適切な統制があれば、未承認の変更、不正なアクセス、データ消失、システム停止といったリスクを抑えやすくなります。
特に、売上や在庫、給与、経費、仕訳などの処理をシステムに依存している場合、システムの処理結果が正しいと説明できることが重要です。IT全般統制は、システムの出力データや自動チェック機能を財務報告に利用するための土台になります。
IT全般統制が不十分な場合に生じるリスク
IT全般統制が不十分な場合、財務報告に誤りが生じるリスクだけでなく、業務停止や情報漏えいにつながるおそれがあります。主なリスクは次のとおりです。
- 退職者や異動者のアカウントが残り、不正アクセスや不適切な操作が行われる
- 承認やテストを経ない変更により、会計処理やデータ連携に不具合が生じる
- バックアップや復旧手順が不十分で、障害時にデータを復元できない
- システム障害やバッチ処理の失敗を見逃し、決算処理が遅延する
- 外部委託先の管理状況を確認しておらず、委託先の不備が自社の財務報告に影響する
統制の不備が見つかった場合、直ちに開示すべき重要な不備になるとは限りません。ただし、影響範囲を調査し、補完できる統制があるかを確認したうえで、速やかに改善する必要があります。
J-SOXとIT統制の全体像
J-SOXが求める財務報告の信頼性
J-SOXが求める中心的な目的は、投資家などに開示する財務報告の信頼性を確保することです。経営者は、自社の内部統制が有効に機能しているかを評価し、内部統制報告書として報告します。外部監査人は、その経営者評価を監査します。
現在の企業活動では、多くの取引がシステムを通じて処理されています。そのため、経理部門だけで正確性を確認するのではなく、取引データを作成・連携・保存するシステムの管理状況も確認する必要があります。
内部統制におけるIT統制の役割
内部統制には、業務の有効性と効率性、報告の信頼性、法令などの遵守、資産の保全という目的があります。IT統制は、これらの目的をITの観点から支える仕組みです。
J-SOXでは、内部統制を構成する基本的な要素の一つとしてITへの対応が位置づけられています。ITへの対応は、単なるセキュリティ対策ではありません。財務報告に関わる処理が正しく継続されるよう、システムの利用、運用、変更、委託先管理を含めて考える必要があります。
IT全社的統制・IT全般統制・IT業務処理統制の違い
IT統制は、実務上、対象範囲と役割に応じて3つに整理すると理解しやすくなります。
- IT全社的統制は、ITに関する方針、組織体制、責任分担、リスク管理、情報セキュリティ方針など、全社共通の枠組みです
- IT全般統制は、システムが安定して安全に運用されるための共通的な管理です。アクセス管理、変更管理、運用管理、外部委託先管理などが中心となります
- IT業務処理統制は、個別の業務システムに組み込まれた統制です。入力値のチェック、自動計算、承認ワークフロー、データ連携時の照合などが該当します
IT全社的統制が方針と体制、IT全般統制がシステム運用の基盤、IT業務処理統制が日々の取引処理を担う関係にあります。
IT全般統制とIT業務処理統制の関係
IT業務処理統制は、取引が正確かつ漏れなく処理されることを直接支える仕組みです。たとえば、入力金額が一定の範囲を超えた場合にエラーを表示する機能や、未登録の取引先では登録できない機能が該当します。
ただし、こうした機能があっても、誰でも設定を変更できる状態であれば、その有効性は保てません。プログラムや設定を変更する際に承認やテストが行われ、利用者の権限が適切に管理されていることが必要です。この前提を支えるのがIT全般統制です。
IT全般統制が有効であっても、個別のIT業務処理統制が有効であるとは限りません。両者は役割が異なるため、それぞれを評価する必要があります。
IT全般統制の対象となるシステムと範囲の決め方
財務報告に影響する業務とシステムを洗い出す
IT全般統制の対象を決める際は、まず財務報告に関係する業務とシステムを把握します。売上、購買、在庫、固定資産、給与、経費、会計、連結決算、開示などの業務について、どのシステムが使われ、どのように会計数値につながるかを整理します。
この段階では、会計システムだけでなく、会計システムへデータを連携する販売管理システムや在庫管理システムも確認対象になります。システム間の連携、データベース、認証基盤、クラウドサービスなども、財務データに重要な影響を与える場合があります。
会計システムと周辺システムの対象範囲
会計システムは多くの場合、IT全般統制の対象になります。しかし、対象は会計システムだけに限られません。たとえば、販売管理システムから売上データが会計システムへ連携される場合、販売管理システムのデータが不正確であれば、会計処理にも影響します。
対象範囲を検討する際は、取引の開始から財務諸表への反映までを追うことが有効です。取引データを入力するシステム、データを加工・連携する仕組み、会計処理を行うシステム、決算や開示に利用するシステムを一連の流れとして把握します。
クラウドサービスや外部委託先を含めた考え方
会計システムや給与計算システムをクラウドサービスで利用している場合でも、財務報告に関係する限り、IT統制の対象として検討します。サービス提供事業者がシステムを運用しているからといって、自社の管理責任がなくなるわけではありません。
外部委託先やクラウドサービスを利用する場合は、契約内容、責任分担、障害時の連絡方法、データ管理、再委託の有無などを確認します。委託先が提供するSOC報告書などの第三者報告書を入手できる場合は、対象期間、対象サービス、例外事項、自社側で対応すべき統制を確認し、評価記録を残します。
SOC報告書がない場合には、委託先への質問票、監査報告書、認証取得状況、契約書、運用報告などを組み合わせ、必要な統制状況を確認します。
重要性とリスクに応じて評価範囲を絞り込む
J-SOXでは、すべてのシステムを一律に評価するのではなく、財務報告への影響とリスクに応じて対象を決めます。金額的重要性だけでなく、不正が起こりやすい取引、複雑な取引、見積もりを含む処理、過去に不備があった領域なども考慮します。
評価範囲を絞り込む際には、対象に含めた理由だけでなく、対象外とした理由も記録しておくことが重要です。組織変更、システム更改、M&A、クラウド移行、重要な障害などが発生した場合は、前年の範囲をそのまま使わず、改めて見直します。
IT全般統制で押さえる4つの管理領域
アクセス管理：利用者登録・権限付与・定期見直し
アクセス管理は、システムやデータを利用できる人を適切に限定するための統制です。利用者の登録、権限付与、異動時の変更、退職時の削除、定期的な権限の見直しを管理します。
基本となる考え方は、業務上必要な範囲に限って権限を付与することです。特に、仕訳入力と承認、プログラム開発と本番環境への反映など、一人で不正や誤りを完結できる権限の組み合わせがないかを確認します。
アクセス管理では、次のような証跡を残します。
- 利用者登録、変更、削除の申請と承認記録
- 利用者ごとの権限一覧
- 定期的な権限棚卸しの結果と承認記録
- 特権IDの利用記録
- 退職者や異動者のアカウント削除・変更記録
変更管理：プログラムや設定変更の申請・承認・記録
変更管理は、プログラム、設定、マスタデータ、システム連携などを変更する際に、未承認または不適切な変更が本番環境に反映されることを防ぐ仕組みです。
一般的には、変更申請、影響確認、承認、テスト、本番反映、反映後の確認という流れを定めます。変更内容、理由、影響範囲、実施者、承認者、テスト結果を記録し、後から確認できる状態にします。
緊急変更が必要な場合にも、通常の手続きを省略したままにしないことが重要です。緊急対応後に承認を取得し、変更理由、対応内容、影響確認、再発防止策を記録する運用を整えます。
開発・導入管理：新システム導入時のテストと承認
開発・導入管理は、新しいシステムの導入や大規模な改修において、業務要件や統制要件が適切に反映されることを確認する仕組みです。導入後に会計処理やデータ連携の誤りが見つかると、決算や開示に大きな影響が及ぶ可能性があります。
要件定義の段階から、必要な承認機能、入力チェック、アクセス権、ログ取得、データ連携、バックアップなどを検討します。本番稼働前には、テスト計画、テスト結果、移行結果、利用部門の承認、稼働判定の記録を残します。
開発担当者と本番環境の運用担当者を分けるなど、職務を分けることも重要です。少人数で完全に分けられない場合には、第三者によるレビューや事後確認といった補完的な統制を設けます。
運用管理：障害対応・バックアップ・復旧手順
運用管理は、システムを日常的に安定稼働させ、障害やデータ消失が起きた場合に迅速に対応するための統制です。対象には、ジョブ管理、バッチ処理の監視、障害対応、バックアップ、復旧、ログ管理、パッチ適用などが含まれます。
バックアップは取得するだけでは十分ではありません。実際に復元できるかを確認する復旧テストを定期的に実施し、その結果を記録する必要があります。また、障害が発生した場合は、発生日時、影響範囲、対応者、復旧日時、原因、再発防止策を記録します。
決算に必要な処理が止まった場合に、誰が検知し、誰が判断し、どのように復旧するかを明確にしておくことが重要です。
外部委託先管理：委託先の統制確認と責任分担
外部委託先管理は、システムの開発、保守、運用、データ処理などを外部に任せる場合に必要となる統制です。業務を委託しても、財務報告に係る内部統制の最終的な責任は自社に残ります。
契約段階では、業務範囲、責任分担、情報管理、障害報告、監査協力、再委託、データ返却や削除などを明確にします。利用開始後は、サービス水準、障害、変更、セキュリティ事故、第三者報告書、改善状況を定期的に確認します。
自社と委託先のどちらが実施する統制なのかを明確にし、自社側で行うべきアカウント管理、権限棚卸し、出力結果の確認などを漏れなく実施することが重要です。
J-SOX対応に向けたIT全般統制の構築手順
担当部門と責任者を明確にする
IT全般統制は、情報システム部門だけで完結するものではありません。経営者が最終責任を持ち、経理、内部監査、情報システム、業務部門が連携して進める必要があります。
まず、対象システムごとに、システム責任者、統制の実施者、証跡の保管者、評価担当者を明確にします。統制を実施する部門と、その有効性を評価する部門は、できるだけ役割を分けることが望まれます。
現状の運用と管理ルールを確認する
次に、現在どのようなルールと運用が存在するかを確認します。規程や手順書がある場合でも、実際の運用と一致していないことがあります。文書だけで判断せず、担当者へのヒアリング、画面確認、ログ確認、申請記録の確認を組み合わせることが重要です。
確認対象には、システム一覧、構成図、データ連携図、アカウント一覧、変更管理票、障害記録、バックアップ記録、委託先一覧、契約書などがあります。
ITリスクを特定して必要な統制を設計する
現状を把握した後は、財務報告への影響を踏まえてITリスクを特定します。たとえば、退職者アカウントが残るリスク、不適切な変更が本番環境に反映されるリスク、障害により決算データが失われるリスクなどです。
リスクを整理したうえで、それを抑えるための統制を設計します。すでに有効な統制があれば活用し、不足がある場合は新たなルールや仕組みを整備します。統制は厳しすぎると現場に定着しにくいため、リスクの大きさと業務負荷のバランスを考慮します。
業務記述書・フローチャート・証跡を整備する
J-SOX対応では、業務の流れ、リスク、統制、証跡の関係を文書化します。一般的には、業務記述書、フローチャート、リスク・コントロール・マトリクスを整備します。
IT全般統制では、対象システム、対象となるIT基盤、統制の内容、実施頻度、担当者、証跡の保管場所、評価方法を整理します。特に、リスクと統制、証跡の対応関係を明確にすると、監査時の説明がしやすくなります。
運用テストと評価を行い改善につなげる
統制は、設計されているだけでは不十分です。実際に決めた手順どおりに運用されているかを確認する必要があります。これを運用状況評価といいます。
たとえば、アクセス権棚卸しが定期的に行われているか、変更管理で承認とテストの記録が残っているか、バックアップと復旧テストが実施されているかを、証跡に基づいて確認します。
不備が見つかった場合は、原因、影響範囲、補完統制の有無、改善策、改善期限を整理します。期末までに是正した場合でも、是正後の統制が有効に運用されたことを確認できるようにします。
監査で確認されるポイントと運用時の注意点
統制が設計されているだけでなく実行されているか
監査では、規程や手順書が存在するかだけでなく、統制が実際に運用されているかが確認されます。たとえば、変更管理規程があっても、実際の変更に承認記録やテスト結果がなければ、運用されているとは評価しにくくなります。
統制の実施頻度に応じて、日次、月次、四半期、年次などの記録を継続して残すことが必要です。期末直前にまとめて作成するのではなく、日常業務の中で証跡が残る運用にします。
承認記録や操作履歴などの証跡を残せているか
監査対応では、統制を実施した事実を示す証跡が重要です。口頭での説明や担当者の記憶だけでは、十分な根拠になりません。
証跡としては、申請書、承認履歴、チケット、メール、システムログ、操作履歴、テスト結果、棚卸し記録、障害報告書などがあります。誰が、いつ、何を確認し、どのように承認したかを追跡できる状態で保管します。
証跡の保管場所、命名ルール、保管期間、閲覧権限を決めておくと、監査時に資料を探す負担を軽減できます。
退職者アカウントや過剰な権限が放置されていないか
アクセス管理では、退職者のアカウント、異動後も残った旧部署の権限、共有アカウント、過剰な管理者権限が重点的に確認されます。
人事部門からの入退社・異動情報とシステムのアカウント情報を連携させるか、定期的に突合する仕組みを整えます。特に財務データにアクセスできるシステムでは、退職時の削除手続きと、定期的な権限棚卸しを確実に実施することが重要です。
例外対応が承認・記録・見直しされているか
システム障害や緊急変更など、通常の手順どおりに対応できない場面は発生します。こうした例外対応が必要なこと自体は問題ではありませんが、無承認で処理され、記録も残らない状態はリスクになります。
例外が発生した場合は、理由、影響範囲、実施内容、承認者、事後確認、再発防止策を記録します。例外対応が頻繁に起きる場合は、通常のルールやシステム設計に課題がある可能性もあるため、定期的に見直します。
組織変更やシステム変更に合わせて統制を更新できているか
IT全般統制は、一度整備すれば終わりではありません。組織変更、人事異動、システム更改、クラウド移行、委託先変更、新規サービス導入などがあると、統制の前提も変わります。
変更があった際には、対象範囲、リスク、責任分担、手順書、権限設定、証跡の保管方法を見直します。前年の文書や評価範囲をそのまま使うのではなく、当年度のIT環境と業務実態に合わせて更新し続けることが、J-SOX対応における重要なポイントです。
