IT全般統制とは｜J-SOXにおけるアクセス権限・変更管理・運用管理の実務ポイント

J-SOX対応におけるIT全般統制は、会計システムや業務システムが「正しく動いていること」を漠然と確認するためのものではありません。

より正確にいえば、財務報告に関係するシステムとデータが、継続して信頼できる状態で運用されるための基盤統制です。

販売管理システムで売上データが生成される。購買システムから仕入・債務データが会計システムに連携される。給与計算システムの結果が人件費として計上される。ワークフローで承認された支払データがインターネットバンキングに連携される。連結決算システムや開示資料作成ツールを使って、有価証券報告書の基礎資料が作られる。

このような会社では、個別の業務処理統制が適切に設計されていても、その前提となるシステムのアクセス権限、変更管理、運用管理が弱ければ、統制の有効性を説明しきれなくなります。

たとえば、売上計上ロジックがシステムに組み込まれていたとしても、承認なしにプログラムや設定を変更できる状態であれば、その自動処理を信頼してよいのか疑問が残ります。支払承認ワークフローが整っていても、退職者IDや不要権限が残っていれば、承認統制が実質的に迂回される可能性があります。バックアップを取得していても、復旧できるか確認されていなければ、障害時に決算・開示へ与える影響を説明できません。

内部統制は、「業務の有効性及び効率性」「報告の信頼性」「事業活動に関わる法令等の遵守」「資産の保全」という目的を合理的に保証するためのプロセスであり、6つの基本的要素の一つとしてITへの対応が位置づけられています。組織の業務内容がITに大きく依存している場合や、情報システムがITを高度に取り入れている場合には、ITへの対応は内部統制の目的を達成するために欠かせない要素とされています。
出典：金融庁｜財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準

本稿では、J-SOX上のIT全般統制について、特に実務上の手戻りが起こりやすいアクセス権限、変更管理、運用管理を中心に整理します。

IT全般統制は、IT業務処理統制を支える土台である

J-SOXにおけるIT統制は、大きく分けると、IT全社統制、IT全般統制、IT業務処理統制に整理されます。

このうちIT全般統制は、IT業務処理統制が継続的に有効に機能する環境を支える統制です。IT全般統制は、IT環境の継続的かつ適切な運用を支援する企業のITプロセスに係る内部統制と説明されています。そして、経営者が財務報告において依拠する内部統制が自動化されている程度が高いほど、自動化された情報処理統制を支援するIT全般統制の重要性は高くなります。
出典：日本公認会計士協会｜監査基準報告書315実務ガイダンス第1号

たとえば、販売管理システムで売上金額が自動計算され、会計システムへ自動連携される場合、その自動処理はIT業務処理統制に近い論点です。

しかし、その売上計算ロジックやマスタ情報、データ連携処理が、誰でも変更できる状態であれば、その自動処理を継続して信頼することはできません。

この「自動処理を信頼できる状態」を支えるのがIT全般統制です。

実務上も、IT全般統制はIT業務処理統制が継続的に有効に機能する環境を保証するための統制活動であり、通常、複数の業務処理統制に関係する方針と手続として整理されます。

したがって、IT全般統制を考えるときは、次の順番で考える必要があります。

まず、財務報告に関係する業務処理がある。

次に、その業務処理の一部がシステムに依存している。

さらに、そのシステムが継続して正しく機能するために、アクセス権限、変更管理、運用管理などの統制が必要になる。

この順番を飛ばして、単に「アクセス権限一覧を確認する」「変更申請書を保存する」「バックアップを取得する」と考えてしまうと、J-SOX上の目的が見えなくなります。

IT全般統制で扱う主な領域

IT全般統制で扱う領域は、会社のシステム環境や評価範囲によって異なりますが、J-SOX実務では主に次のような領域が問題になります。

• アクセス権限管理
• ID管理
• 特権ID管理
• プログラム変更管理
• システム開発・改修管理
• 本番環境へのリリース管理
• システム運用管理
• ジョブ管理
• インターフェース管理
• バックアップ・リカバリ
• 障害管理
• ログ管理
• 情報セキュリティ管理
• 外部委託先管理
• クラウドサービス利用時の会社側統制

ITへの対応は、IT環境への対応、ITの利用、IT統制から構成され、IT統制はさらにIT全社的統制、IT全般統制、IT業務処理統制に区分されると整理されています。財務報告に関係する財務情報を識別、把握、処理、伝達するための会計システムは適切に統制されていなければならず、会計システムで利用されるITにも、財務情報が適切に統制され、財務報告の信頼性が確保されるような統制機能が求められます。
出典：経済産業省｜システム管理基準 追補版（財務報告に係るIT統制ガイダンス）

ただし、ここで注意しておきたいのは、IT全般統制を情報システム管理全般に広げすぎないことです。

J-SOX上のIT全般統制は、会社のすべてのIT管理を評価するものではありません。財務報告に重要な影響を与えるシステム、アプリケーション、データ、IT基盤に焦点を当てる必要があります。

IT全般統制の評価単位は「会社全体」ではなく「IT基盤・システム環境」で考える

IT全般統制は、全社的内部統制と混同されやすい領域です。

たしかに、アクセス権限管理や変更管理の方針は、会社全体のルールとして定められることがあります。しかし、J-SOX上の評価では、実際にはどのIT基盤・どのシステム環境で統制が機能しているかを確認する必要があります。

たとえば、販売管理システム、在庫管理システム、会計システムが同じIT基盤上で一体運用されている会社と、各システムが別々のクラウドサービスや子会社ごとのローカル環境で運用されている会社では、評価単位は変わります。

制度上も、IT統制についてすべてを同一のIT基盤で集中管理することは求められておらず、企業内にIT基盤が複数認められる場合には、個々のIT基盤を評価単位としてITに係る全般統制の評価を行うとされています。
出典：金融庁｜内部統制報告制度に関するQ&A

したがって、IT全般統制の整備では、まず次の点を整理することが重要です。

• 財務報告に関係するアプリケーションは何か
• そのアプリケーションは、どのIT基盤上で動いているか
• そのIT基盤は、自社運用か、子会社運用か、外部委託か、クラウドか
• アクセス権限、変更管理、運用管理の責任者は誰か
• 同じ方針・手続で管理されている範囲はどこまでか
• 別々に評価すべきIT基盤やサービスはどれか

この整理をしないまま、会社全体で一つのIT全般統制として評価しようとすると、監査法人との認識が合わなくなりやすくなります。

アクセス権限管理｜「誰が何をできるか」を財務報告リスクから見る

IT全般統制の中でも、最も基本的でありながら、実務上の不備が起こりやすいのがアクセス権限管理です。

アクセス権限管理の目的は、単にIDを管理することではありません。財務報告に影響するデータや処理に対して、権限のない者がアクセスし、登録、変更、削除、承認、出力、直接修正できないようにすることです。

アクセス権の管理・運用が適切に行われていない場合、マスタファイルの未承認変更、システムやプログラムの未承認変更、承認を経ない仕訳データの直接変更、データ消失やアクセス不能といったリスクにつながる可能性があります。
出典：日本公認会計士協会｜ITを利用した情報システムに関する重要な虚偽表示リスクの識別と評価及び評価したリスクに対応する監査人の手続について

アクセス権限管理では、少なくとも次の観点を確認する必要があります。

IDの新規付与

新しい利用者にIDを付与する場合、その申請者、承認者、付与者、付与内容が明確になっている必要があります。

実務上問題になりやすいのは、「入社したから」「部署から依頼があったから」という理由だけで、既存担当者と同じ権限をコピーして付与しているケースです。

J-SOX上は、その権限が業務上必要か、職務分掌に反していないか、財務報告データにどこまで影響するかを確認する必要があります。

特に、会計システム、販売管理システム、購買管理システム、在庫管理システム、給与計算システム、固定資産管理システム、経費精算システム、支払ワークフローなどでは、入力権限、承認権限、マスタ変更権限、仕訳修正権限、管理者権限を分けて検討すべきです。

異動・退職時の権限削除

退職者ID、異動前部署の権限、長期間未使用のIDが残っている状態は、IT全般統制上の典型的な弱点です。

特に、退職者IDが残っていても「実際には使われていないはず」と説明するだけでは不十分です。必要なのは、人事情報とID管理が連動しており、退職・異動の情報が適時にIT部門またはシステム管理者へ伝達され、不要権限が削除されていることを証跡で説明できる状態です。

削除日、削除対象、削除承認、削除実施者、削除後の確認が残っているかが重要になります。

定期的な権限レビュー

アクセス権限は、一度正しく設定すれば終わりではありません。

組織変更、担当変更、業務分掌の見直し、システム更新、子会社統合、クラウド移行などにより、権限は徐々に実態とずれていきます。

そのため、定期的なアクセス権限レビューが必要になります。

ただし、アクセス権限一覧を出力して、部門長が確認印を押すだけでは実効性が弱くなります。レビューでは、次のような観点が必要です。

• 退職者や異動者のIDが残っていないか
• 担当業務に不要な権限が残っていないか
• 入力権限と承認権限が同一人物に集中していないか
• マスタ変更権限が過剰に付与されていないか
• 管理者権限や特権IDの利用者が限定されているか
• 子会社や外部委託先のユーザー権限が放置されていないか
• 共有IDや汎用IDが利用されている場合、その利用記録を追跡できるか

重要なのは、「見た」ことではなく、「何を基準に問題ないと判断したのか」です。

特権ID管理

特権IDは、通常のユーザーIDよりも慎重に管理すべきです。

特権IDを使えば、システム設定の変更、ユーザー権限の付与・削除、データベースへの直接アクセス、ログの閲覧・削除、本番環境への反映など、財務報告に影響する処理が可能になる場合があります。

特権ID管理では、次の点を確認します。

• 特権IDの利用者が限定されているか
• 特権IDの利用申請・承認があるか
• 利用目的、利用日時、作業内容が記録されているか
• 作業後にログレビューが行われているか
• 緊急利用の場合、事後承認や事後レビューが行われているか
• 特権IDを日常業務用IDとして使っていないか
• ベンダーや外部委託先に特権IDを付与している場合、責任分界と利用記録が明確か

特権IDは、内部統制を迂回できる入口になり得ます。したがって、特権IDの管理が弱い場合、単なるIT管理上の不備にとどまらず、業務処理統制や証跡管理の信頼性にも影響します。

変更管理｜「何を、なぜ、誰が承認して変えたか」を説明する

変更管理は、IT全般統制の中でも監査法人から確認されやすい領域です。

変更管理の目的は、システムの改修や設定変更を妨げることではありません。財務報告に影響するプログラム、設定、マスタ、インターフェース、計算ロジック、帳票出力、権限設計などが、承認なく変更されたり、テスト不十分なまま本番反映されたりしないようにすることです。

プログラム変更の管理に不備があると、修正されるべきプログラムの不具合が残り、誤った処理が継続してしまう可能性があります。
出典：日本公認会計士協会｜ITを利用した情報システムに関する重要な虚偽表示リスクの識別と評価及び評価したリスクに対応する監査人の手続について

実務上も、システム開発・変更管理では、開発・変更担当と運用担当の分離、開発計画の承認、システム変更の承認、成果物の承認、テスト結果の承認、本番リリースの承認、データ移行計画・移行結果の承認などが具体例として整理されます。

変更管理で確認すべき主な論点は、次のとおりです。

変更依頼の起点

変更管理では、まず変更依頼の起点が明確である必要があります。

誰が、なぜ、その変更を依頼したのか。

その変更は、業務改善なのか、法令・会計基準対応なのか、監査法人指摘への対応なのか、障害対応なのか。

そして、財務報告に影響する変更なのか。

この起点が曖昧なまま進むと、後から「なぜこの設定を変えたのか」「会計処理への影響を誰が確認したのか」を説明できなくなります。

影響度評価

変更管理で特に重要なのは、変更の影響度評価です。

IT部門から見ると軽微な変更でも、経理・財務・開示の観点では重要な変更であることがあります。たとえば、販売管理システムの消費税区分、売上計上日、リベート計算、単価マスタ、在庫評価、給与計算条件、勘定科目変換ルール、連結パッケージ項目、開示集計ロジックなどは、財務報告に直接影響します。

したがって、変更管理では、IT部門だけでなく、業務部門、経理部門、必要に応じて内部監査部門が影響を確認する必要があります。

影響度評価では、次の観点を確認します。

• 重要な勘定科目に影響するか
• 会計仕訳や開示資料に影響するか
• 既存のIT業務処理統制に影響するか
• データ連携やインターフェースに影響するか
• 既存の3点セット、RCM、業務記述書、フローチャートの更新が必要か
• 運用評価の対象期間や評価方法に影響するか
• 監査法人への事前説明が必要か

テストとユーザー受入確認

変更管理では、テストの実施と承認が重要です。

ただし、単に「テスト済み」と記録されているだけでは不十分です。J-SOX上は、財務報告に影響する観点から、どのようなテストを行い、誰が結果を確認し、なぜ本番反映してよいと判断したのかを説明できる必要があります。

たとえば、売上計上ロジックの変更であれば、想定される取引パターンごとに、売上金額、売上日、税区分、得意先、請求データ、会計仕訳への連携結果を確認する必要があります。給与計算条件の変更であれば、勤怠、基本給、手当、控除、社会保険、源泉税、支払データ、会計計上への影響を確認する必要があります。

テスト環境と本番環境が分離されているか、テストデータが妥当か、テスト結果に対する利用部門の承認があるかも重要です。

本番リリース承認

開発やテストが終わっていても、本番環境への反映は別の統制点です。

本番反映の承認者、実施者、実施日、反映対象、反映後確認が明確でなければ、変更管理は完結しません。

特に、システム部門の担当者が開発、テスト、本番反映、運用を一人で行っている場合、職務分掌上のリスクがあります。人数が限られる会社では完全な分離が難しい場合もありますが、その場合でも、利用部門の承認、作業ログのレビュー、事後確認、管理者によるモニタリングなどの代替統制を検討する必要があります。

緊急変更管理

障害対応や法令対応などで、通常の変更管理手続を経ずに緊急リリースが必要になる場合もあります。

この場合に重要なのは、緊急対応を禁止することではありません。緊急対応を例外として管理し、事後的に承認、テスト、レビュー、影響確認を行うことです。

緊急変更が頻発している場合は、単なる例外処理ではなく、通常の開発・保守プロセスや運用管理に構造的な問題がある可能性があります。

運用管理｜「止まらないこと」だけでなく「異常を把握し、対応できること」が重要

IT全般統制における運用管理は、システムが稼働していることを確認するだけの領域ではありません。

財務報告に関係する処理が、予定どおり、正しく、網羅的に実行され、異常が発生した場合には適時に把握・対応されることを支える統制です。

実務上も、システム運用に係る全般統制では、ジョブスケジュール管理、臨時処理、情報システムの稼働確認、バックアップデータの保管、障害発生時の復旧などが識別・評価の対象として整理されます。

ジョブ管理

会計・販売・購買・在庫・給与・連結・開示に関係するシステムでは、夜間バッチ、月次締め処理、データ連携、残高更新、仕訳生成、帳票出力などのジョブが実行されることがあります。

ジョブ管理では、次の点を確認します。

• 重要ジョブの一覧があるか
• 実行スケジュールが定められているか
• ジョブ変更には承認があるか
• ジョブの成功・失敗が監視されているか
• エラー発生時の対応手順があるか
• 臨時ジョブの実行が管理されているか
• 月次・四半期・期末決算時の特別処理が管理されているか

特に、販売管理システムから会計システムへの連携、給与計算結果から会計仕訳への連携、連結決算パッケージの取込などは、失敗しても気づかなければ、財務報告に直接影響します。

インターフェース管理

複数システム間でデータ連携がある場合、インターフェース管理も重要です。

自動連携されているから安全、というわけではありません。連携処理では、未連携、重複連携、エラー除外、文字化け、桁数制限、項目マッピング誤り、連携後の手修正などが起こり得ます。

インターフェース管理では、次の点を確認します。

• 連携元と連携先が明確か
• 連携対象データの件数・金額を確認しているか
• エラーデータの検出と修正手順があるか
• 連携処理の失敗が担当者に通知されるか
• 手作業で補正する場合、承認と証跡が残るか
• 会計システムへの取込後に総勘定元帳や補助簿と照合されているか

インターフェース管理は、IT業務処理統制と密接に関係します。ただし、連携処理を支えるジョブ、権限、変更、ログ、エラー監視は、IT全般統制上の論点になります。

バックアップと復旧

バックアップは、取得しているだけでは足りません。

J-SOX上重要なのは、財務報告に必要なデータを、必要な時点に、必要な粒度で復旧できるかです。

複雑ではないIT環境においても、権限のないデータ変更を防ぐアクセス統制、必要なソフトウェアが適切にアップデートされたことを確認する内部統制、財務諸表を作成するのに必要なデータのバックアップに関する内部統制等を特に重要と考えて監査が実施される場合があります。
出典：日本公認会計士協会｜財務報告に係る内部統制の監査

バックアップ・復旧では、次の点を確認します。

• 対象システムと対象データが明確か
• バックアップ頻度が決算・開示上の要求に合っているか
• 保存期間が十分か
• バックアップデータへのアクセス権限が管理されているか
• 復旧テストが実施されているか
• 復旧手順が文書化されているか
• クラウドサービスの場合、会社側で何を確認すべきか整理されているか
• バックアップ失敗時の通知と再取得が管理されているか

特に注意すべきなのは、クラウドサービスを利用している場合です。サービス事業者側でバックアップが取られていても、会社側が必要な時点のデータを復旧できるか、誤削除や誤更新に対してどの範囲まで復元できるかは、サービス内容や契約条件によって異なります。

障害管理

障害管理では、システム障害そのものよりも、障害が財務報告に与える影響をどう把握し、対応するかが重要です。

たとえば、月次決算中に会計システムが停止した場合、決算スケジュールに影響します。販売管理システムから会計システムへの連携が失敗した場合、売上計上に影響します。給与計算システムの処理エラーが発生した場合、人件費計上や支払処理に影響します。連結決算システムや開示資料作成ツールの障害は、有価証券報告書や決算短信の作成にも影響します。

障害管理では、次の点を確認します。

• 障害の発生日時、内容、影響範囲が記録されているか
• 財務報告に影響する障害かどうかを判定しているか
• 経理部門、情報システム部門、業務部門の連携があるか
• 暫定対応と恒久対応が区別されているか
• 再発防止策が検討されているか
• 重要障害が経営層や内部監査部門に報告されているか
• 監査法人への共有が必要な障害を識別しているか

障害対応は、単なるIT運用報告ではなく、財務報告リスクの早期把握にもつながります。

IT全般統制の不備は、直ちに開示すべき重要な不備となるのか

IT全般統制に不備が見つかった場合、それだけで直ちに開示すべき重要な不備になるわけではありません。

ITに係る全般統制は、財務報告の重要な事項に虚偽記載が発生するリスクへ直接につながるものでは必ずしもないため、全般統制に不備が発見されたとしても、直ちに開示すべき重要な不備と評価されるものではないとされています。たとえば、プログラム変更管理に不備がある場合でも、事後的に業務処理統制に係る実際のプログラムに変更がないことを確認できたようなときには、稼働中の情報処理システムに係る業務処理統制とは関連性が薄いため、当該システムの内部統制は有効に機能していると位置づけられる場合があります。
出典：金融庁｜内部統制報告制度に関するQ&A

ただし、これは「IT全般統制の不備は軽い」という意味ではありません。

IT全般統制に不備がある場合、IT業務処理統制が継続的に有効に機能する環境を保証できない可能性があります。アクセス権限管理が弱ければ、承認統制やマスタ管理統制が迂回される可能性があります。変更管理が弱ければ、自動計算やデータ連携の前提が崩れる可能性があります。運用管理が弱ければ、ジョブ失敗、連携エラー、データ消失、障害による決算遅延が見逃される可能性があります。

したがって、不備が見つかった場合には、次の順に整理する必要があります。

• どのIT全般統制に不備があるのか
• どのシステム、IT基盤、業務プロセスに影響するのか
• どのIT業務処理統制に依拠していたのか
• 実際にプログラム、設定、データ、権限に問題が発生していないか
• 補完統制や実証的な確認で財務報告リスクを低減できるか
• 不備の発生可能性と影響額はどの程度か
• 是正完了までの期間に、どのような追加手続を実施するか

この整理がないまま、「IT全般統制の不備は直ちに重要ではない」と処理してしまうと、監査法人との協議で手戻りが生じやすくなります。

期末前のシステム変更は避けるべきか

J-SOX対応では、期末前のシステム変更を一律に避けようとする会社があります。

たしかに、期末近くに財務報告へ重要な影響を与えるシステム変更を行うと、評価手続や監査対応が難しくなる場合があります。しかし、制度上、期末前の一定期間にシステム変更を行ってはならないとされているわけではありません。

企業が業務改善等の観点からシステム変更等を行うことは企業の判断であり、内部統制監査を実施しにくくなることをもって、期末日前の一定期間にシステム変更等を行うべきでないと監査人が結論づけることは適切でないとされています。一方で、重要な影響を及ぼす変更がある場合には、経営者は重要な変更部分について追加手続の実施を検討する必要があります。
出典：金融庁｜内部統制報告制度に関するQ&A

つまり、問題は「期末前に変更したこと」ではありません。

問題は、変更の重要性を判断し、変更管理手続を実施し、必要に応じて追加評価を行い、監査法人に説明できる状態にしているかです。

期末前のシステム変更では、特に次の点を整理します。

• 変更対象システムが財務報告に影響するか
• 変更内容が勘定科目、仕訳、計算ロジック、データ連携、開示資料に影響するか
• 既存のIT業務処理統制に影響するか
• 変更前後で評価対象期間を分ける必要があるか
• 追加の整備評価、運用評価、再テストが必要か
• 監査法人と事前に協議すべきか
• 3点セット、RCM、業務記述書、フローチャートの更新が必要か

「凍結するかどうか」ではなく、「変更を説明できるかどうか」で判断することが重要です。

小規模・成長企業では、どこまでIT全般統制を整えるべきか

IPO準備会社や成長企業では、情報システム部門が十分に整っていないこともあります。経理部門がSaaSを管理し、管理者権限も経理担当者が持っている。外部ベンダーが保守を行い、社内には詳細を理解している人が少ない。ExcelやCSVを多用し、システム間連携が手作業に近い。こうした状態は珍しくありません。

このような会社で、いきなり大企業と同じレベルのIT全般統制を導入しようとすると、現場が回らなくなります。

一方で、上場会社または上場準備会社として、財務報告に重要な影響を与えるシステムについて「誰が何をできるか」「変更は誰が承認したか」「障害やエラーを把握できるか」を説明できない状態は、監査・上場審査・内部監査の観点からリスクになります。

複雑ではないIT環境では、すべての統制領域を広く深く評価するのではなく、財務報告に直結する重要な統制に絞って整備することが現実的です。実務指針上も、複雑ではないIT環境では、アクセス統制、ソフトウェアの適切なアップデート、財務諸表作成に必要なデータのバックアップに関する内部統制等を特に重要と考えて監査が実施される場合があるとされています。
出典：日本公認会計士協会｜財務報告に係る内部統制の監査

したがって、初期段階では、次の順番で優先順位をつけることが有効です。

1つ目は、財務報告に関係するシステムを特定すること。

2つ目は、そのシステムの管理者権限と利用者権限を整理すること。

3つ目は、退職・異動時のID削除と定期的な権限レビューを始めること。

4つ目は、財務報告に影響する変更について、申請・承認・テスト・本番反映の証跡を残すこと。

5つ目は、重要データのバックアップと復旧手順を確認すること。

6つ目は、障害や連携エラーが発生した場合の経理部門への連絡ルートを明確にすること。

これだけでも、J-SOX上の説明可能性は大きく変わります。

SaaS・クラウド利用時のIT全般統制

SaaSやクラウドサービスを利用している場合、IT全般統制の考え方は少し複雑になります。

サーバー、ネットワーク、データベース、バックアップ、アプリケーション運用の一部をサービス提供事業者が担っている一方で、ユーザー権限、承認フロー、マスタ設定、会社側のデータ入力、システム利用方法、出力データのレビューなどは会社側に残ることが多いためです。

つまり、クラウドだからIT全般統制が不要になるわけではありません。

むしろ、次のように責任分界を整理する必要があります。

• サービス提供事業者が担う統制は何か
• 会社側が担う統制は何か
• SOC報告書等で確認できる範囲はどこまでか
• 会社側の相補的統制は何か
• ユーザーID、権限、承認フロー、マスタ設定は誰が管理するか
• データエクスポート後のExcel加工や会計取込は誰がレビューするか
• 障害通知やメンテナンス情報を誰が受け取り、財務報告影響を判断するか

特にSaaSでは、利用部門が簡単に設定変更できることがあります。承認経路、勘定科目変換、税区分、マスタ項目、帳票設定、ワークフロー条件などの変更が財務報告に影響する場合には、通常のシステム開発ほど大掛かりでなくても、変更管理の対象として扱う必要があります。

IT全般統制の評価で確認すべき証跡

J-SOX対応では、統制を実施しているだけでは足りません。後から説明できる証跡が必要です。

IT全般統制では、次のような証跡が実務上重要になります。

アクセス権限管理の証跡

• ID新規発行申請
• 権限付与承認
• 異動・退職時の削除記録
• 権限変更申請
• 定期的なアクセス権限レビュー記録
• 特権ID利用申請・承認
• 特権ID利用ログ
• 管理者によるログレビュー記録

変更管理の証跡

• 変更依頼書
• 影響度評価
• 業務部門・経理部門の承認
• 開発・改修記録
• テスト計画
• テスト結果
• ユーザー受入確認
• 本番リリース承認
• リリース後確認
• 緊急変更の事後承認・事後レビュー

運用管理の証跡

• ジョブスケジュール
• ジョブ実行結果
• エラーログ
• エラー対応記録
• インターフェース照合記録
• バックアップ取得記録
• 復旧テスト記録
• 障害管理票
• 障害影響分析
• 再発防止策
• 重要障害の報告記録

証跡の品質で重要なのは、「資料があること」ではありません。

誰が、何を、いつ、どの観点で確認し、どのように判断したのかが読み取れることです。監査法人や内部監査が後から確認したときに、統制の目的と実施結果がつながっている必要があります。

IT全般統制でよくある不備

IT全般統制では、次のような不備がよく見られます。

権限一覧はあるが、レビュー観点がない

権限一覧を出力して保管しているものの、誰が何を確認したかが分からない状態です。

確認印だけでは、不要権限、退職者ID、職務分掌違反、特権ID、共有IDの妥当性を検討したとはいえません。

退職者IDや異動前権限が残っている

人事情報とID管理が連携していない場合に起こりやすい不備です。

退職者IDが残っていること自体も問題ですが、それ以上に、退職・異動情報がシステム管理に伝達される仕組みがないことが問題です。

特権IDを日常的に使っている

管理者IDを通常業務で使っている場合、誰がどの操作を行ったか追跡しにくくなります。

また、特権IDの利用ログを取得していても、レビューしていなければ統制としては弱くなります。

システム変更に経理部門が関与していない

IT部門やベンダー主導で変更が行われ、経理部門が財務報告影響を確認していないケースです。

売上計上、仕入計上、在庫評価、給与計算、支払、連結、開示に影響する変更については、経理部門または業務責任者の確認が必要です。

テスト証跡が不十分

「テスト済み」と記載されているだけで、テスト条件、テスト結果、レビュー、承認が残っていない状態です。

財務報告に影響する変更では、何をもって問題ないと判断したのかを説明できる必要があります。

バックアップはあるが、復旧確認がない

バックアップを取得しているものの、復旧テストが行われていないケースです。

障害発生時に復旧できるか分からなければ、決算・開示への影響を抑える統制としては不十分です。

障害管理がIT部門内で閉じている

障害情報がIT部門内で記録されていても、財務報告に影響するかどうかが経理部門に共有されていないケースです。

J-SOX上は、障害が会計処理、データ連携、決算スケジュール、開示資料に影響するかを判断する必要があります。

IT全般統制を整えると、決算・開示・経営管理にも効いてくる

IT全般統制は、監査法人に説明するためだけに整えるものではありません。

アクセス権限が整理されると、承認権限や職務分掌も見直しやすくなります。変更管理が整うと、システム改修時に会計・決算・開示への影響を事前に把握しやすくなります。運用管理が整うと、ジョブ失敗やデータ連携エラーを早期に検知でき、月次決算や四半期決算の手戻りを減らせます。

決算早期化の実務では、単体決算、連結決算、開示業務を分断せず、最終成果物から逆算して業務を組み立てる視点が重要になります。決算・開示担当者が「森を見る視点」を持てない場合、手待ち、手戻り、重複が生じやすくなります。

IT全般統制も同じです。

アクセス権限、変更管理、運用管理をそれぞれ個別のIT作業として見るのではなく、財務報告データが発生し、処理され、会計に連携され、決算・開示資料に反映されるまでの流れの中で見る必要があります。

IT全般統制が整うことで、次のような効果が期待できます。

• 財務報告データの信頼性を説明しやすくなる
• 監査法人からの手戻りを減らしやすくなる
• 決算処理やデータ連携のエラーを早期に把握しやすくなる
• 業務変更やシステム変更時の影響を事前に把握しやすくなる
• 子会社やクラウドサービスを含むシステム管理の責任分界が明確になる
• 内部監査部門が評価しやすい統制資料を整備しやすくなる
• IPO準備や上場後運用に耐える管理体制を作りやすくなる

IT全般統制を見直すときの実務ステップ

IT全般統制を見直す際は、いきなり詳細なチェックリストを作るのではなく、次の順番で整理することが重要です。

1. 財務報告に関係するシステムを洗い出す

最初に、会計システムだけでなく、販売、購買、在庫、給与、固定資産、経費精算、ワークフロー、連結、開示、BI、データ連携ツール、Excel・EUCを含めて洗い出します。

2. IT基盤・運用責任者を整理する

各システムがどのIT基盤で運用されているか、自社管理か、子会社管理か、外部委託か、クラウドかを整理します。

3. アクセス権限の実態を確認する

ID一覧、権限一覧、管理者権限、退職者ID、共有ID、外部委託先IDを確認します。

ここでは、一覧を集めるだけでなく、財務報告に影響する権限を特定することが重要です。

4. 変更管理の流れを確認する

財務報告に関係する変更が、申請、承認、影響度評価、テスト、本番反映、事後確認の流れで管理されているか確認します。

SaaSの設定変更やワークフロー変更も、財務報告に影響する場合には対象に含めます。

5. 運用管理・障害管理を確認する

重要ジョブ、データ連携、バックアップ、復旧、障害対応、エラー処理を確認します。

特に、月次・四半期・期末決算で使う処理については、経理部門とIT部門の認識を合わせる必要があります。

6. 証跡の残し方を設計する

統制が実施されていても、証跡が残らなければ評価・監査に耐えません。

申請書、承認記録、ログ、レビュー結果、障害管理票、バックアップ記録、復旧テスト記録などを、誰が、どこに、どの期間保存するかを決めます。

7. 監査法人と早めに認識合わせをする

IT全般統制は、評価範囲、評価単位、サンプル、証跡、クラウドサービスの扱いについて、監査法人と認識がずれやすい領域です。

期末に近づいてから協議すると、手戻りが大きくなります。評価計画の段階で、対象システム、IT基盤、アクセス権限、変更管理、運用管理、クラウド・外部委託の扱いを整理しておくことが望まれます。

IT全般統制について専門家に相談すべき場面

次のような状況がある場合、IT全般統制の整理を社内だけで進めるのは難しくなりやすいです。

• 財務報告に関係するシステムの範囲が整理できていない
• 監査法人からアクセス権限、変更管理、運用管理について指摘を受けている
• ID管理や権限レビューが形式的になっている
• 退職者ID、共有ID、特権IDの管理に不安がある
• システム変更時に経理部門が関与していない
• テスト証跡や本番反映承認が残っていない
• クラウドサービスや外部委託先の統制範囲が曖昧
• 子会社ごとにシステムや運用が異なり、親会社として把握しきれていない
• IPO準備や上場後運用に向けて、IT統制の水準を引き上げたい
• IT統制を決算早期化や開示品質向上につなげたい

IT全般統制は、情報システム部門だけで完結する論点ではありません。財務報告リスク、業務フロー、権限設計、証跡管理、監査法人対応、内部監査、決算・開示体制をつなげて整理する必要があります。

犬飼公認会計士・税理士事務所では、J-SOX対応を形式的な文書化作業ではなく、決算・開示・業務プロセス・IT・証跡管理をつなぐ「説明できる会社づくり」として整理する支援を行っています。

アクセス権限、変更管理、運用管理、クラウド利用、監査法人からのIT統制指摘、IPO準備段階での内部管理体制整備などに課題がある場合は、まず現在のシステム範囲と財務報告データの流れを整理することが有効です。

J-SOXにおけるIT全般統制を、自社の決算・開示・経営管理にどう接続すべきかを確認したい場合は、犬飼公認会計士・税理士事務所HPのお問い合わせページよりご相談ください。

出典・参考情報

• 出典：金融庁｜財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準
• 出典：金融庁｜内部統制報告制度に関するQ&A
• 出典：金融庁｜「内部統制報告制度に関するQ&A」等の改訂について
• 出典：経済産業省｜システム管理基準 追補版（財務報告に係るIT統制ガイダンス）
• 出典：日本公認会計士協会｜監査基準報告書315実務ガイダンス第1号
• 出典：日本公認会計士協会｜財務報告に係る内部統制の監査
• 出典：日本公認会計士協会｜ITを利用した情報システムに関する重要な虚偽表示リスクの識別と評価及び評価したリスクに対応する監査人の手続について

重要事項の振り返り

論点	実務上のポイント
IT全般統制の位置づけ	IT業務処理統制が継続して有効に機能するための基盤統制
評価単位	会社全体で一括せず、財務報告に関係するシステム・IT基盤単位で整理する
アクセス権限管理	ID新規付与、異動・退職時削除、定期レビュー、特権ID管理を証跡で説明できるようにする
変更管理	変更依頼、影響度評価、テスト、ユーザー承認、本番反映、事後確認を管理する
運用管理	ジョブ、データ連携、バックアップ、復旧、障害対応を財務報告影響と結びつけて管理する
バックアップ	取得しているだけでなく、財務報告に必要なデータを復旧できるかを確認する
障害管理	障害が会計処理、決算、開示に与える影響を経理・IT・内部監査で共有できるようにする
IT全般統制の不備	直ちに開示すべき重要な不備とは限らないが、IT業務処理統制への影響を検討する必要がある
期末前のシステム変更	一律禁止ではなく、重要性判断、追加評価、監査法人との協議が重要
最終目的	IT統制を監査対応だけでなく、決算早期化、開示品質、権限設計、経営管理体制の強化につなげる