ITGC（IT全般統制）評価の実務｜アクセス管理・変更管理・運用管理の要点

内部統制報告制度（J-SOX）の評価において、IT全般統制（ITGC）は多くの企業が負担を感じている領域です。「どのシステムを評価対象にすればよいか分からない」「IT部門に何を依頼すればよいか整理できていない」「毎年同じ不備を指摘されてしまう」といった声は少なくありません。本記事では、J-SOX の評価を担当する内部監査部門や内部統制推進部門、そして評価を受ける IT 部門の担当者に向けて、ITGC の基本的な考え方と評価対象の決め方、アクセス管理・変更管理・運用管理の領域別の評価ポイント、よくある不備と評価チェックリストを整理します。

ITGC（IT全般統制）とは

IT全般統制とは、業務処理統制が有効に機能する環境を保証するための統制で、複数の業務処理統制に関係する方針と手続を指します。財務報告に係る内部統制の評価及び監査に関する実施基準では、IT全般統制の例として次のようなものが挙げられています。

• システムの開発、保守に係る管理
• システムの運用・管理
• 内外からのアクセス管理などシステムの安全性の確保
• 外部委託に関する契約の管理

実務では、これらを「プログラム開発」「プログラム変更」「アクセス管理（セキュリティ）」「コンピュータ運用」といった領域に整理して評価することが一般的です。本記事では、評価の負担が大きく不備も生じやすいアクセス管理、変更管理、運用管理の 3 領域を中心に解説します。

ITGC が重要とされるのは、業務処理統制、特にシステムによる自動化された統制（ITAC）の有効性を支える土台だからです。たとえば、販売管理システムで与信限度額を超える受注を自動的に止める統制があっても、誰でもその設定を変更できる状態であれば、自動統制が継続して機能しているとはいえません。ITGC が有効であることで、自動統制を一度テストすれば、その後も同じように機能していると判断しやすくなります。自動統制の評価方法については「ITAC（IT業務処理統制）の評価手順と自動統制のテスト方法」で詳しく解説しています。

評価対象システムの選定

ITGC の評価は、すべての社内システムを対象にするわけではありません。財務報告に影響する業務処理統制が依拠しているシステムを特定し、そのシステムに関係する ITGC を評価します。

対象システムを特定する手順

1. 評価範囲とした業務プロセスの業務記述書やリスクコントロールマトリクス（RCM）から、IT に依拠している統制（自動統制、システムが出力するレポートを使う手作業の統制など）を洗い出す
2. それらの統制が依拠しているアプリケーション（会計システム、販売管理システム、購買システムなど）を特定する
3. アプリケーションを支える基盤（データベース、OS、ネットワーク、クラウド環境）と、その運用主体（自社 IT 部門、グループ会社、外部委託先）を整理する
4. システムごとに、ITGC を評価する単位（同じ運用ルールで管理されているシステム群をまとめるかどうか）を決める

外部委託・クラウドの扱い

システムの運用を外部に委託している場合や、SaaS を利用している場合は、委託先側の統制を自社で直接評価することが難しくなります。その場合は、受託会社の内部統制に関する保証報告書（SOC1 報告書など）の入手と評価、利用者側で実施すべき統制（ユーザー管理など）の評価を組み合わせます。詳しくは「クラウド・SaaS利用時の内部統制とSOC報告書の読み方」を参照してください。

ITGC の主な評価領域と統制例

領域ごとの代表的なリスクと統制、評価で確認する証跡の例を整理すると次のとおりです。

アクセス管理の評価ポイント

アクセス管理は、ITGC の中で最も不備が指摘されやすい領域の一つです。評価では次の観点を確認します。

ID のライフサイクル管理

入社・異動・退職に伴う ID の登録、権限変更、削除が、承認に基づいて適時に行われているかを確認します。運用評価では、対象期間中の新規登録や権限変更からサンプルを抽出して承認記録と照合するほか、人事部門の退職者リストとシステムのユーザー一覧を突き合わせ、退職後も有効なままの ID がないかを確認します。

定期的な権限の見直し

利用者の権限が職務に照らして適切かを、業務部門の責任者が定期的に確認しているかを評価します。形式的な確認にならないよう、見直しに使ったユーザー一覧がシステムから網羅的に出力されたものか、見直しの結果として不要な権限が実際に削除されたかまで確認することが重要です。

特権 ID の管理

システム管理者権限などの特権 ID は、データの直接更新や設定変更が可能なため、利用者の限定、利用時の申請と承認、利用記録の事後確認といった統制が求められます。共有の管理者アカウントを使っている場合は、誰がいつ使ったのかを特定できる仕組みがあるかを確認します。

認証設定の確認

パスワードの長さや有効期限、ロックアウトの設定、多要素認証の適用範囲など、認証に関する設定が社内のセキュリティ規程に沿っているかも確認します。シングルサインオンを導入している場合は、個々のアプリケーションではなく認証基盤側の設定を確認することになるため、どのシステムがどの認証基盤に依拠しているかを整理しておくと評価が効率的です。

アクセス管理の運用評価手続の例

アクセス管理の運用評価では、統制ごとに母集団とテストの方法を決めておきます。代表的な例は次のとおりです。

サンプル数は、統制の実施頻度や自社の評価方針を踏まえ、必要に応じて監査人と協議して決めます。

変更管理の評価ポイント

変更管理では、本番環境のプログラムや設定の変更が、承認とテストを経て行われているかを評価します。

変更の網羅性の確認

運用評価で最初に確認すべきなのは、テスト対象とする変更一覧が網羅的であるかという点です。変更管理台帳に記録された変更だけを母集団にすると、台帳に載っていない変更を見逃すおそれがあります。可能であれば、システムの変更履歴や本番環境のプログラムの更新日時と台帳を突き合わせ、台帳への記録漏れがないことを確認します。

承認・テスト・移行の分離

変更の申請、承認、テスト、本番移行が適切な担当者により行われているかを確認します。特に、開発者が自ら本番環境に移行できる状態は職務分離の観点から問題とされやすいため、移行権限の付与状況を確認します。小規模な組織で完全な分離が難しい場合は、移行後の変更内容を別の担当者が確認するなどの代替的な統制があるかを評価します。

緊急変更の扱い

障害対応などで事前承認を経ずに行う緊急変更については、事後承認のルールとその運用状況を確認します。緊急変更の件数が多い場合は、通常の変更手続を回避する手段として使われていないかにも注意が必要です。

変更管理の評価で確認する事項

変更管理の運用評価では、抽出した変更ごとに次の事項を確認し、結果を調書に記録します。

• 変更申請に、変更の目的と内容、影響範囲が記載されているか
• 変更の承認が、本番移行より前に権限のある者によって行われているか
• テストが実施され、その結果を利用部門または責任者が確認しているか
• 本番移行を行った者が開発者と異なるか（異ならない場合は代替的な統制があるか）
• 移行後に、意図した変更のみが反映されていることを確認しているか

パッケージソフトや SaaS のバージョンアップのように、自社で開発しない変更についても、適用前の影響確認と承認の手続があるかを確認対象に含めます。

運用管理の評価ポイント

運用管理では、財務データを処理するジョブやバッチ処理が正確かつ網羅的に実行されていること、障害が発生した場合に適切に対応されていることを評価します。

• ジョブスケジュールの登録や変更が承認に基づいて行われているか
• ジョブの異常終了が検知され、原因の調査と再実行が記録されているか
• 財務データのバックアップが定期的に取得され、復旧できることを確認しているか
• 障害の記録から、財務データに影響した事象がないかを確認しているか

運用評価では、対象期間の障害記録やジョブの異常終了の記録から、財務報告に影響し得るものを抽出し、対応が適切に完了しているかを確認します。

ジョブ管理ツールや監視ツールで異常終了を自動通知している場合は、通知の設定内容と、通知を受けた担当者の対応記録の両方を確認します。通知設定が変更されていないことを確かめるには、ツールの設定変更も変更管理の対象に含まれているかを見ておく必要があります。また、財務データの受け渡しを他システムとのインターフェースで行っている場合は、連携処理の異常を検知する仕組みがあるかも確認対象になります。

バックアップについては、取得の設定や取得結果のログを確認するだけでなく、実際にデータを復旧できることを確かめた記録があるかを確認します。復旧テストを行っていない場合、障害時に初めてバックアップが使えないことが判明するおそれがあります。復旧テストの頻度や範囲は、システムの重要性に応じて社内の規程で定め、その結果と、問題があった場合の対応を記録として残しておくことが望まれます。

評価の進め方と IT 部門との連携

ITGC の評価を円滑に進めるには、評価者と IT 部門の役割分担を明確にしておくことが大切です。評価計画の段階で、対象システム、評価する統制、依頼する資料と提出期限を IT 部門と共有しておくと、資料の往復が減ります。

また、J-SOX 2024 改訂では、IT全般統制の運用評価を一定の複数会計期間に一度とする取扱いについて、特定の年数を機械的に適用せず、IT 環境の変化等を踏まえて慎重に判断することが明確化されました。ローテーション評価を採用している場合でも、変更の有無を毎期確認できる根拠を整えておく必要があります。前年度から変更がないことを示すには、変更管理台帳だけでなく、システムの変更履歴やバージョン情報などの客観的な記録を用いるのが望ましいでしょう。

IT 部門への依頼資料リストの例

評価計画の段階で依頼資料をリストにして共有しておくと、準備の抜け漏れと資料の往復を減らせます。

システムから出力した一覧を評価に使う場合は、出力の条件や手順を確認し、一覧が網羅的で正確であることを確かめておきます。

よくある不備の傾向

ITGC の評価で指摘されやすい不備には、一定の傾向があります。退職者の ID が削除されずに残っている、権限の見直しが実施されていても結果の記録が残っていない、変更管理台帳に記録されていない本番変更がある、特権 ID の利用記録を誰も確認していない、といったものです。いずれも統制のルール自体は存在していても、運用の記録や確認が伴っていないことに起因する場合が多く、評価計画の段階で IT 部門と「どの記録を残せば統制が機能していると説明できるか」を合意しておくことが予防につながります。

不備が識別された場合の検討

ITGC に不備が見つかった場合は、その不備が業務処理統制や財務報告にどのような影響を与え得るかを検討します。たとえば退職者の ID が残っていた場合、その ID が退職後に実際に使われたかどうかをアクセスログで確認し、使用されていなければ財務データへの影響はないと判断できる場合があります。また、同じリスクに対応する他の統制（補完統制）が有効に機能していれば、不備の影響が軽減されることもあります。こうした検討の経緯は調書に記録し、必要に応じて監査人と協議します。

ITGC 評価チェックリスト

評価の準備と実施状況を確認するためのチェックリストです。

評価計画

• 評価範囲の業務処理統制が依拠するシステムと基盤を特定しているか
• システムの運用主体（自社・グループ会社・委託先・SaaS 事業者）を整理しているか
• 委託先・SaaS について、保証報告書の入手可否と対象範囲を確認したか
• ローテーション評価の場合、変更の有無を確認する根拠を定めているか

アクセス管理

• ID の登録・変更・削除の承認記録を確認したか
• 退職者リストとユーザー一覧を突き合わせたか
• 権限の見直しに使った一覧の網羅性と、見直し後の権限削除を確認したか
• 特権 ID の利用者と利用記録の確認状況を評価したか

変更管理・運用管理

• 変更一覧の網羅性を、システムの変更履歴などと突き合わせて確認したか
• 承認・テスト・本番移行の職務分離、または代替的な統制を確認したか
• 緊急変更の事後承認の状況を確認したか
• ジョブの異常終了と障害の対応記録を確認したか
• バックアップの取得と復旧の確認状況を評価したか

よくある質問

SaaS の保証報告書が入手できない場合はどうすればよいですか

保証報告書が入手できない場合は、サービス事業者が公表しているセキュリティに関する情報や認証の取得状況、契約上の取決めを確認するとともに、利用者側で実施できる統制（ユーザー管理、データの入出力の照合など）を強化して対応することが考えられます。財務報告への影響が大きいシステムであれば、評価方針について早めに監査人と協議しておきます。

小規模な IT 部門で職務分離ができない場合はどう評価しますか

担当者が少なく、開発と本番移行を同じ担当者が行わざるを得ない場合は、変更後に別の担当者や業務部門の責任者が変更内容を確認する、本番環境の変更履歴を定期的にレビューするといった代替的な統制を整備し、その運用を評価します。代替的な統制の内容と記録の方法を、あらかじめ文書化しておくことが大切です。

ITGC に不備があると、自動統制の評価はすべてやり直しになりますか

必ずしもそうとは限りません。不備の内容が自動統制の設定やプログラムに影響し得るものかを検討し、影響し得る場合は、対象期間を通じて自動統制が意図どおりに機能していたかを追加の手続で確認します。たとえば、設定の変更履歴を確認して期間中に変更がなかったことを確かめる、自動統制を期末時点で再度テストするといった対応が考えられます。

まとめ

ITGC の評価では、まず財務報告に関係する業務処理統制が依拠するシステムを特定し、評価対象を適切に絞り込むことが出発点になります。そのうえで、アクセス管理では ID の管理と権限見直しの実効性、変更管理では母集団の網羅性と職務分離、運用管理では異常の検知と対応を重点的に確認します。統制ごとに母集団とテストの方法を決め、依頼資料のリストを IT 部門と早期に共有しておくと、評価の効率と精度が高まります。委託先・クラウドを含めた評価方針の整理や、職務分離が難しい場合の代替的な統制の設計も欠かせません。本記事のチェックリストを活用し、自社の ITGC 評価の手順を点検してみてください。

関連サービス

• IT監査・ITガバナンス支援
• J-SOX（内部統制）評価支援