IT部門・経理部門・内部監査の連携｜J-SOXでIT統制を「説明できる状態」にする実務設計

J-SOX対応でIT統制がうまく進まない会社には、共通した構図があります。

経理部門は「システムのことはIT部門に聞いてほしい」と考える。IT部門は「会計やJ-SOXのことは経理部門で判断してほしい」と考える。そして内部監査部門は「評価資料が揃わないのでテストできない」と悩む。

監査法人からは、システム台帳、アクセス権限、変更管理、インターフェース、ログ、電子証跡、クラウド利用、SOCレポートについて質問が届きます。ところが、社内の誰が回答責任を持つのかが曖昧なまま、時間だけが過ぎていきます。

この状態では、IT統制は「情報システム部門のチェックリスト」になり、J-SOX全体から分断されてしまいます。

しかし、J-SOX上のIT統制は、情報システム部門だけで完結する論点ではありません。財務報告に関係するシステムとデータが、どの業務プロセスを通じて、どの勘定科目・開示項目に影響し、どの統制でリスクを低減しているのか。それを説明するための仕組みです。

つまり、IT部門、経理部門、業務部門、内部監査部門が共通認識を持たなければ、IT統制は設計できず、評価もできず、監査法人にも説明できません。

この記事では、J-SOXにおけるIT部門・経理部門・内部監査の連携を、責任分担、システム台帳、業務フロー、IT依存統制、評価資料、監査法人対応の観点から整理します。ここで扱うのは、IT全般統制そのものの詳細手続やクラウド・外部委託先評価の個別論点ではありません。それらを社内でどうつなぎ、継続運用できる体制にするかです。

J-SOX上のIT統制は「ITの問題」ではなく「財務報告の説明責任」の問題である

J-SOXにおけるIT統制の出発点は、システムの安全性そのものではありません。財務報告の信頼性に影響するシステム・データ・処理・証跡を、会社として説明できるかどうかです。

金融庁の2023年改訂意見書では、「情報と伝達」において、大量の情報を扱う状況等で情報の信頼性を確保するうえでシステムが有効に機能することの重要性が示されています。また「ITへの対応」では、IT委託業務に係る統制の重要性や、サイバーリスクの高まり等を踏まえた情報システムのセキュリティ確保の重要性が挙げられています。
出典：金融庁｜財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）

ここから分かるのは、IT統制が単なるサイバーセキュリティ施策やシステム管理規程の有無ではないということです。財務報告に利用される情報の信頼性を支える統制、と捉えるべきものです。

たとえば、販売管理システムから会計システムへ売上データが連携される場合を考えてみます。IT部門は連携仕様や権限設定を理解していても、売上計上リスクや期間帰属リスクの重要性までは判断しにくいものです。

一方、経理部門は売上計上のリスクを理解していても、インターフェースエラー、マスタ権限、プログラム変更、ログ保存といった技術的な確認までは単独で判断しにくい。内部監査部門は評価者として独立性を保つ必要がある一方で、評価対象となる統制がどこにあり、どの証跡で確認できるのかを理解しなければ評価できません。

したがって、J-SOX上のIT統制では、次の3つをつなげる必要があります。

視点	主に理解している部門	J-SOX上つなげるべき内容
財務報告リスク	経理部門、開示部門	どの勘定科目・開示項目に重要な虚偽表示リスクがあるか
システム・データ処理	IT部門、システム管理部門	どのシステム・マスタ・自動処理・連携・ログが関係するか
評価・監査対応	内部監査部門、J-SOX事務局	どの統制を、どの証跡で、どの頻度で評価するか

この3つが分断されたままでは、IT統制は形式的な資料作成にとどまります。

IT部門任せにすると、なぜ手戻りが起きるのか

IT部門は、システム構成、インフラ、アクセス権限、変更管理、障害対応、バックアップ、ログ管理などを理解しています。J-SOXにおいて不可欠な存在です。

しかし、IT部門だけでは決められないことがあります。それは、そのシステムや設定が「財務報告上どれほど重要か」という判断です。

たとえば、同じクラウドサービスであっても、単なる社内コミュニケーションツールと、売上計上データを生成する販売管理システムでは、J-SOX上の意味がまったく異なります。

同じアクセス権限でも、閲覧権限と、売上マスタ・単価マスタ・仕訳データを変更できる権限では、財務報告リスクが異なります。同じシステム変更でも、画面レイアウト変更と、収益認識の自動計算ロジック変更では、評価の重さが異なります。

IT部門任せにすると、次のような手戻りが起こりやすくなります。

起こりやすい手戻り	原因
評価対象システムが広がりすぎる	財務報告上の重要性を踏まえず、IT部門の管理対象をそのままJ-SOX対象にしている
重要なシステムが漏れる	経理・現場が利用しているSaaSやExcel連携がIT部門の台帳に載っていない
アクセス権限レビューが形式化する	権限が会計上どのリスクに関係するか整理されていない
変更管理の証跡が不足する	システム変更の財務報告影響を経理部門が確認していない
監査法人への回答が噛み合わない	技術的説明と会計リスクの説明が分断されている
内部監査の評価調書が弱い	統制目的、証跡、実施者、頻度の対応関係が不明確

IT部門は「システムがどう動いているか」を説明できます。しかしJ-SOXでは、「そのシステムが財務報告リスクにどう関係し、そのリスクにどの統制が効いているか」まで説明する必要があります。

ここに、経理部門と内部監査部門の関与が必要になります。

経理部門任せにしても、IT統制は設計できない

反対に、経理部門だけでもIT統制は設計できません。

経理部門は、重要な勘定科目、決算・開示プロセス、会計上の見積り、非定型取引、監査法人対応を理解しています。しかし、システム構成、権限設計、プログラム変更、インターフェース、ログ取得、クラウドの責任分界などを技術的に把握していなければ、統制の実効性を判断できません。

たとえば、経理部門が「売上データは販売管理システムから会計システムに連携されている」と理解していても、実務上は次の確認が必要になります。

確認項目	経理部門だけでは見落としやすい点
データ連携方式	API連携か、CSV手動取込か、RPAか、手入力か
連携対象データ	売上金額、税額、得意先、部門、商品、計上日、取消・返品情報
エラー処理	連携失敗時に誰が検知し、誰が修正し、誰が再実行するか
マスタ権限	得意先マスタ、単価マスタ、勘定科目マスタを誰が変更できるか
変更管理	収益認識や税率、締め処理に影響する仕様変更がどう承認されるか
ログ	変更履歴や承認履歴が評価時点で取得できるか
帳票の完全性	出力帳票がシステム内データを漏れなく反映しているか

ITの利用から生じるリスクについては、企業のITプロセスにおける内部統制のデザインまたは運用が有効でないことにより、情報処理統制が有効に機能しない可能性、そして情報システム内のデータの網羅性・正確性・正当性に対して生じるリスクとして整理されています。
出典：日本公認会計士協会｜監査基準報告書315実務ガイダンス第1号 ITの利用の理解並びにITの利用から生じるリスクの識別と評価に関する実務ガイダンス

つまりIT統制では、会計上のリスク理解と、ITプロセスの理解の両方が欠かせません。経理部門がIT部門へ質問し、IT部門が経理部門へ財務報告上の重要性を確認する。この往復がなければ、統制は表面的なものにとどまります。

内部監査部門は「作る人」ではなく「評価し、改善を促す人」である

IT統制の連携において、内部監査部門の位置づけを誤る会社も少なくありません。

内部監査部門はJ-SOX評価を実施することが多いため、現場から「では、どう設計すればよいですか」「どの証跡を残せばよいですか」と相談されます。もちろん、助言やファシリテーションは有用です。

しかし、内部監査部門が統制の設計・運用を実質的に肩代わりしてしまうと、評価者としての独立性・客観性に影響します。

内部監査には、独立的な評価を提供するアシュアランス業務と、助言・研修・ファシリテーションなどのコンサルティング業務があります。後者を行う場合でも、評価対象を自ら作り込むことによって客観性を損なわないよう、注意が必要です。

内部監査部門の役割は、次のように整理するのが実務的です。

領域	内部監査部門が担うべきこと	担いすぎると危険なこと
評価計画	リスクに基づき評価範囲、評価時期、評価手続を設計する	経理・ITの代わりに統制を運用する
整備評価	統制がリスクに対して設計上有効か確認する	RCMや業務フローを実質的に作成し、承認者になる
運用評価	証跡に基づき統制が継続運用されているか評価する	証跡不足を補うために後付け資料を作る
改善提案	不備原因、是正方向、再評価方法を提示する	是正策の実行責任者になる
監査法人対応	評価結果・調書・証跡を説明する	会社側の統制責任を監査法人に代弁するだけになる

内部監査部門は、IT部門・経理部門と距離を置きすぎても評価できません。逆に近づきすぎると、独立性が曖昧になります。

そのため現実的には、「評価者としての独立性を保ちながら、リスク・統制・証跡の共通理解を作るファシリテーター」として機能することが求められます。

三者連携の出発点は「システム台帳」である

IT部門・経理部門・内部監査が連携するうえで、最初に整えるべき資料はシステム台帳です。

ただし、J-SOX上のシステム台帳は、単なるIT資産一覧では不十分です。サーバー名、ソフトウェア名、契約先、ライセンス数だけが載っていても、財務報告リスクとの関係が分からなければ評価には使えません。

J-SOXで使えるシステム台帳には、少なくとも次の情報が必要です。

項目	記載すべき内容
システム名	会計、販売、購買、在庫、固定資産、給与、経費、ワークフロー、連結、開示等
業務プロセス	どの業務フローで利用されているか
関連勘定科目	売上、売掛金、棚卸資産、買掛金、人件費、固定資産、現預金等
財務報告リスク	実在性、網羅性、正確性、期間帰属、権利義務、表示開示等への影響
システムオーナー	業務責任者、経理責任者、IT責任者
利用部門	実際に入力・承認・出力・照合を行う部署
主な機能	入力、承認、自動計算、マスタ管理、データ連携、帳票出力
連携先	どのシステムへ、どのデータを、どの頻度で連携するか
IT基盤	クラウド、オンプレミス、外部委託、データベース、ネットワーク
主要権限	管理者、承認者、入力者、閲覧者、マスタ変更者
主要証跡	承認履歴、操作ログ、変更履歴、エラーログ、帳票、照合記録
変更管理	仕様変更、バージョンアップ、リリース承認の管理方法
J-SOX評価区分	評価対象、参考対象、対象外、その理由

財務報告に係るIT統制では、まず評価対象となるIT業務処理統制を特定し、関連するアプリケーションを特定し、その後にIT基盤とIT全般統制の範囲を特定していく。この発想が有効です。

社内に存在するすべてのシステムについてIT全般統制を評価する必要は、必ずしもありません。財務報告リスクと関連するIT業務処理統制に影響を与えるIT全般統制を見極めることが重要です。

ここで大切なのは、システム台帳をIT部門だけで作らないことです。

IT部門が一次情報を整備し、経理部門が財務報告への影響を付け加え、内部監査部門が評価可能性を確認する。この三者レビューを経て、はじめてJ-SOXで使えるシステム台帳になります。

業務フローとシステム台帳をつなげる

システム台帳だけでは、取引の流れが見えません。業務フローだけでは、システム処理の信頼性が見えません。J-SOXでは、この2つをつなげる必要があります。

たとえば販売プロセスでは、次のように業務とシステムが連動します。

業務段階	主な処理	関係するシステム	見るべき統制
受注	得意先・契約条件・単価を登録	販売管理、CRM	受注承認、マスタ権限
出荷・役務提供	出荷実績・提供実績を記録	在庫管理、販売管理	出荷データの正確性、取消処理
検収	顧客検収情報を登録	販売管理、外部ポータル	検収証跡、期間帰属
売上計上	売上データを生成	販売管理、会計	自動計算、計上日、税率
会計連携	仕訳を作成・取込	会計システム	インターフェース照合、エラー処理
請求	請求書発行	請求管理	請求データの網羅性
入金消込	入金を売掛金へ消込	会計、入金消込	消込ルール、滞留債権レビュー

業務フローの理解は、内部統制の整備、全体最適化、専門家としての指導、業務フロー構築のいずれにも直結します。典型的な業務フローを理解したうえで、なぜそのフローになっているのか、どのリスクを低減しているのかを考える。それが内部統制設計の近道です。

IT部門は、システム間のデータ連携や権限を説明できます。経理部門は、どの段階で会計処理が発生し、どの証跡が決算・監査に必要かを説明できます。内部監査部門は、どの統制がキーコントロールで、どの証跡を評価対象にするかを判断します。

この3つがつながると、業務フローは単なる手順書ではなくなります。財務報告リスクとIT統制を結びつける説明資料になります。

IT依存統制を明確にする

J-SOXで見落としやすいのが、IT依存統制です。

IT依存統制とは、形式上は人がレビューや承認をしているものの、その判断の前提となる帳票、データ、一覧表、ワークフロー、ログ、アラートなどがシステムから出力されている統制をいいます。

たとえば、次のような統制です。

統制例	IT依存部分
経理責任者が売上明細と会計仕訳を照合する	売上明細がシステムから完全・正確に出力されているか
部門長が経費申請を承認する	ワークフローの承認ルートが正しく設定されているか
給与計算結果を人事部門がレビューする	勤怠データ・人事マスタ・給与計算ロジックが正しいか
固定資産台帳と会計残高を照合する	固定資産台帳の登録・除却・償却計算が正しいか
滞留債権リストをもとに貸倒引当金を検討する	滞留日数・入金消込データが正しく集計されているか
連結パッケージの異常値をレビューする	子会社入力データ、換算、連結調整、消去処理が正しいか

IT依存統制を明確にしないと、人によるレビュー統制だけを評価してしまい、その前提となるシステム出力の信頼性を見落とします。

内部監査部門は、統制を評価する際に「この統制は、どのシステム帳票・データ・ログに依存しているか」を確認する必要があります。経理部門は「その帳票を使って何を判断しているのか」を説明し、IT部門は「その帳票やデータがどのように生成され、誰が変更できるのか」を説明する。この役割分担が欠かせません。

変更管理は、IT部門だけで完結させてはいけない

システム変更管理は、IT全般統制の中核となる論点です。しかしJ-SOX上は、IT部門の変更申請・承認・テスト・リリースだけを確認しても不十分な場合があります。

財務報告に影響するシステム変更については、経理部門や業務部門が「会計処理・決算・開示に影響がないか」を確認する必要があります。

たとえば、次のような変更は、IT部門だけで判断すべきではありません。

変更内容	経理部門が確認すべき影響
売上計上日ロジックの変更	期間帰属、収益認識、検収基準への影響
税率・税区分設定の変更	消費税、請求書、仕訳、申告基礎資料への影響
勘定科目マスタ変更	勘定科目分類、開示科目、管理会計資料への影響
承認ルート変更	権限規程、職務分掌、証跡の有効性への影響
会計連携方式の変更	仕訳の網羅性・正確性、エラー処理への影響
権限ロール変更	不正・誤謬、マスタ改ざん、承認権限への影響
クラウド仕様変更	ログ保存、証跡取得、データ出力、監査対応への影響

変更管理の実務では、変更申請書に「財務報告影響の有無」という欄を設け、経理部門または業務プロセスオーナーが確認する仕組みを作ることが有効です。

また、重要な変更については、内部監査部門やJ-SOX事務局が、RCM・業務フロー・システム台帳の更新要否を確認します。監査法人との協議が必要な場合は、期末を待たず、変更前または変更直後に論点を共有しておきます。

アクセス権限管理は「誰が何をできるか」では足りない

アクセス権限管理では、ユーザー一覧や管理者権限一覧を出すだけでは不十分です。

J-SOX上は、「その権限を持つことで、財務報告上どのようなリスクがあるか」を説明する必要があります。同じ管理者権限であっても、財務報告リスクへの影響は異なります。

権限	財務報告上のリスク
仕訳入力権限	不適切な仕訳、架空計上、期間帰属誤り
仕訳承認権限	承認されていない仕訳の計上、レビュー無効化
勘定科目マスタ変更権限	表示科目、開示科目、集計ロジック誤り
得意先・単価マスタ変更権限	売上金額、請求金額、値引・返品処理の誤り
支払先マスタ変更権限	架空支払、不正支払、振込先改ざん
承認ルート変更権限	権限規程と異なる承認、牽制機能の低下
ログ削除・変更権限	証跡隠蔽、運用評価不能
本番環境直接変更権限	変更管理を経ないプログラム・データ変更

IT部門は、権限一覧を出せます。しかし、どの権限がJ-SOX上重要かは、経理部門と一緒に判断する必要があります。

内部監査部門は、権限棚卸が単なる在籍確認で終わっていないか、職務分掌や承認権限と整合しているかを評価します。

評価資料は「誰が読んでも同じ説明になる」状態にする

J-SOXの評価資料は、評価担当者だけが理解できる資料では不十分です。

経理部門、IT部門、内部監査部門、監査法人が見たときに、少なくとも次の流れが追える必要があります。

1. どの財務報告リスクがあるのか
2. そのリスクに対して、どの業務統制またはIT統制があるのか
3. その統制は、誰が、どの頻度で、どの証跡に基づいて実施しているのか
4. その統制は、どのシステム・データ・ログに依存しているのか
5. そのシステムを支えるIT全般統制は何か
6. 評価者は、どの証跡を見て、有効と判断したのか
7. 例外や不備があった場合、どのように判断し、是正したのか

この説明に必要な資料は、次のように整理できます。

資料	主な作成・更新主体	用途
システム台帳	IT部門、経理部門	評価対象システムの特定
業務フロー	業務部門、経理部門	取引発生から会計処理までの可視化
RCM	経理部門、J-SOX事務局	リスクと統制の対応づけ
IT統制一覧	IT部門、J-SOX事務局	IT全般統制・業務処理統制の整理
権限一覧	IT部門	アクセス権限レビュー
変更管理一覧	IT部門	システム変更の証跡
データ連携一覧	IT部門、経理部門	インターフェースリスクの把握
帳票・ログ一覧	IT部門、経理部門	証跡取得可能性の確認
評価調書	内部監査部門、評価担当	整備評価・運用評価の記録
不備管理表	内部監査部門、J-SOX事務局	不備、原因、是正、再評価の管理
監査法人協議メモ	経理部門、J-SOX事務局	認識合わせと手戻り防止

資料を増やすことが目的ではありません。目的は、同じ事実について、関係者が同じ説明をできる状態にすることです。

監査法人対応では、経理部門が「翻訳者」になる

J-SOXのIT統制に関する監査法人対応では、経理部門の役割が非常に重要になります。

監査法人からの質問は、会計、監査、IT、内部統制の言葉が混在します。一方でIT部門は、技術的な言葉で説明しがちです。

ここで経理部門が間に入り、監査法人の質問意図を社内向けに翻訳し、IT部門や業務部門の回答を監査法人が理解できる形へ整理する。この役割が欠かせません。

監査人対応では、経理部門が監査人の質問内容や要求事項を社内の対応部署が理解できる形に翻訳し、回答が監査人の意図に合うよう促すことが重要です。あわせて、対応内容を監査対応メモとして残しておくことも有効です。

たとえば、監査法人から「この売上帳票の完全性・正確性はどのように担保されていますか」と質問されたとします。このときIT部門が「この帳票はSQLで抽出しています」と答えるだけでは足りません。

必要なのは、次のような説明です。

監査法人の関心	社内で準備すべき説明
帳票の完全性	対象期間・対象取引・抽出条件・除外条件が妥当か
帳票の正確性	元データ、集計ロジック、金額計算、税計算が正しいか
アクセス権限	帳票ロジックや元データを誰が変更できるか
変更管理	帳票仕様が変更された場合、承認・テスト・リリース証跡があるか
業務利用	経理部門がその帳票を使って何をレビューしているか
証跡	レビュー結果、差異対応、承認履歴が残っているか

この「翻訳」ができないと、監査法人対応は技術説明と会計説明の往復になり、手戻りが増えていきます。

連携会議は、年1回では足りない

IT統制の連携は、年次評価の時期だけでは間に合いません。

特に、クラウド利用、システム変更、組織変更、子会社導入、業務フロー変更、会計基準変更、決算早期化プロジェクトがある会社では、少なくとも四半期ごとに、経理・IT・内部監査・J-SOX事務局で論点を共有することが望ましいと考えます。

連携会議で扱うべきテーマは、次のとおりです。

時期	主な確認事項
期首	評価範囲、システム台帳、RCM、評価計画、監査法人協議事項
第1四半期	新規システム、権限変更、業務変更、クラウド導入、証跡取得状況
第2四半期	整備評価、不備候補、変更管理、データ連携、SOCレポート入手状況
第3四半期	運用評価準備、サンプル取得、ログ保存、権限棚卸、是正状況
期末前	決算・開示影響、障害対応、監査法人追加依頼、残課題整理
期末後	不備集計、是正計画、翌期評価範囲、文書更新、改善ロードマップ

ITを利用した内部統制の評価については、特定の年数を機械的に適用するのではなく、IT環境の変化を踏まえて慎重に判断し、必要に応じて監査人と協議すべきことが明確化されています。
出典：金融庁｜財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）

この考え方からすれば、IT統制の連携も、前年踏襲や年1回の資料更新では不十分です。事業・業務・システムの変化を検知し、評価範囲や統制設計へ反映する仕組みが必要になります。

3線モデルで考えると、責任分担が整理しやすい

IT部門・経理部門・内部監査の関係を整理する際は、3線モデルの発想が役に立ちます。

内部統制とガバナンス・全組織的なリスク管理は一体的に整備・運用されることが重要であり、体制整備の考え方として3線モデル等が例示されています。
出典：金融庁｜財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）

これをJ-SOX上のIT統制に当てはめると、次のように整理できます。

区分	主な役割	IT統制での具体例
第1線	業務を実施し、統制を運用する	経理部門、業務部門、IT部門が日常統制を実施する
第2線	方針・標準・モニタリングを支援する	J-SOX事務局、リスク管理、コンプライアンス部門がルール・進捗を管理する
第3線	独立的に評価し、改善を促す	内部監査部門が整備評価・運用評価・不備評価を行う
外部監査人	独立した立場で内部統制監査を行う	監査法人が経営者評価の妥当性を検討する

ここで注意すべきなのは、IT部門は第1線でもあるという点です。IT部門は評価される側であり、統制を運用する主体でもあります。

したがって、内部監査部門がIT部門の統制を評価する際には、IT部門の協力を得ながらも、評価判断は独立して行う必要があります。

小規模組織では「完璧な分離」より「説明できる代替統制」が重要

上場準備会社や中堅規模の会社では、IT部門、経理部門、内部監査部門が十分に分かれていないことがあります。経理責任者がJ-SOX事務局を兼ね、情報システム担当が少人数で、内部監査も専任ではない。こうしたケースは珍しくありません。

この場合、理想的な職務分掌をいきなり求めても、現場で回らない統制になってしまいます。

重要なのは、次の観点で代替統制を設計することです。

制約	現実的な対応例
IT担当者が少ない	特権ID利用時の申請・承認・ログレビューを上位者が実施する
経理とJ-SOX事務局が兼務	評価判断について外部専門家や内部監査担当がレビューする
内部監査が専任でない	評価者の独立性を論点ごとに確認し、自己評価を避ける
業務部門が証跡を残せない	ワークフロー、チェックリスト、月次レビューに組み込む
システム変更が頻繁	重要変更のみJ-SOX影響判定を義務付ける
監査法人対応が属人化	質問・回答・提出資料・合意事項を管理表で記録する

過剰な統制は続きません。しかし、統制不足のままでは説明できません。

少人数体制では、「誰が実施者か」「誰が承認者か」「誰が評価者か」、そして「兼務がある場合の補完手続は何か」を明確にすることが重要です。

部門連携が弱い会社で起こりやすい不備

IT部門・経理部門・内部監査の連携が弱い会社では、次のような不備が起こりやすくなります。

1. 財務報告に関係するシステムが評価範囲に入っていない

経理部門や現場部門が独自に導入したSaaS、スプレッドシート、RPA、BIツール、データ連携ツールが、システム台帳やJ-SOX評価範囲に反映されていないケースです。

売上、在庫、人件費、経費、支払、連結、開示に関係するデータを扱っている場合、IT部門が管理していないからといって、評価不要になるわけではありません。

2. 業務フローとシステム処理が一致していない

3点セットには「担当者が確認する」と書かれているものの、実際にはシステムが自動判定している。あるいは、システム承認の後にExcelで修正している。このような場合、統制設計と運用実態がズレます。

IT部門、経理部門、内部監査が一緒にウォークスルーを行い、業務フロー、システム処理、証跡を突き合わせる必要があります。

3. アクセス権限レビューが在籍確認で終わっている

権限一覧を出して、退職者がいないことだけを確認しているケースです。

J-SOX上は、職務分掌、承認権限、マスタ変更権限、本番環境変更権限、ログ削除権限などを踏まえ、財務報告リスクに照らしたレビューが必要になります。

4. システム変更がRCM・3点セットに反映されていない

販売管理システム、会計システム、連結システム、ワークフロー、クラウドサービスの変更があっても、RCMや業務フローが更新されていないケースです。

変更管理はIT部門の中で完了していても、J-SOX文書が更新されなければ、評価資料としては古いままになります。

5. 内部監査が証跡を取りに行く段階で初めて問題が分かる

運用評価時に、ログが保存期間切れ、承認履歴が出力できない、変更申請が残っていない、SOCレポートの対象期間が不足している。こうした問題が判明するケースです。

これは評価手続の問題ではありません。期中の証跡設計・保存ルール・連携不足の問題です。

6. 監査法人との協議内容が社内に共有されていない

監査法人と経理部門の間では合意しているものの、IT部門や内部監査部門に伝わっていない。あるいは、IT部門が監査法人に直接説明した内容が、経理部門のRCMと整合していない。

この状態では、翌期以降も同じ論点で手戻りが起きます。監査法人協議メモを作成し、関係者で共有することが必要です。

IT統制連携を定着させるための実務ステップ

IT部門・経理部門・内部監査の連携を定着させるには、次の順序で進めるのが現実的です。

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

最初からIT部門の資産台帳をそのまま使うのではなく、経理部門・業務部門に「財務数値や開示資料の作成に使っているシステム・ツール」を確認します。

対象は、基幹システムだけではありません。Excel、Access、BI、RPA、クラウドストレージ、ワークフロー、電子契約、請求書発行ツールも含めて確認します。

ステップ2：業務プロセス・勘定科目・システムを紐づける

販売、購買、在庫、固定資産、人件費、資金、決算・開示の各プロセスについて、関連する勘定科目とシステムを紐づけます。

この段階で、IT部門はシステム機能や連携を説明し、経理部門は財務報告リスクを整理し、内部監査部門は評価対象となり得る統制を確認します。

ステップ3：IT依存統制と自動統制を識別する

人手によるレビュー統制であっても、システム帳票やログに依存している場合は、IT依存統制として整理します。

一方、システムによる自動計算、入力制限、自動承認、エラー検知、マスタ制御は、IT業務処理統制として整理します。

ステップ4：IT全般統制との関係を確認する

自動統制やIT依存統制が有効に機能するためには、アクセス権限、変更管理、運用管理、外部委託管理などのIT全般統制が機能している必要があります。

ただし、すべてのシステムを同じ水準で評価するのではなく、財務報告上重要な統制に影響するIT全般統制を優先します。

ステップ5：評価証跡を事前に確認する

運用評価の時期になってから証跡を探すのではなく、期中に次の点を確認しておきます。

証跡	事前確認すべきこと
承認履歴	誰が、いつ、何を承認したか出力できるか
アクセスログ	保存期間、出力形式、対象ユーザーが適切か
変更管理証跡	申請、承認、テスト、リリースが追跡できるか
エラーログ	エラー検知、修正、再処理の履歴が残るか
帳票	抽出条件、対象期間、集計ロジックを説明できるか
権限棚卸	レビュー対象、実施者、承認者、差異対応が残るか

ステップ6：監査法人と早期に認識合わせを行う

評価範囲、システム台帳、IT依存統制、SOCレポート、変更管理、ログ保存、証跡の提示方法について、期末前に監査法人と協議します。

重要なのは、監査法人に結論を委ねることではありません。会社としての判断根拠を整理し、監査法人の目線と大きなズレがないかを確認することです。

IT部門・経理部門・内部監査の役割分担表

実務では、次のように役割分担を明確にしておくと、責任の空白を防ぎやすくなります。

領域	経理部門	IT部門	内部監査部門
評価範囲判断	財務報告リスク、重要勘定、開示影響を整理	対象システム、IT基盤、連携を説明	判断過程と評価可能性を確認
システム台帳	勘定科目・業務プロセスとの関係を追記	システム構成、権限、運用情報を整備	評価対象との整合性を確認
業務フロー	会計処理、承認、証跡を整理	システム処理、データ連携を補足	統制点と評価証跡を確認
RCM	リスクと統制目的を整理	IT統制、ログ、変更管理を補足	整備評価・運用評価を実施
アクセス権限	財務報告上重要な権限を判断	権限一覧、棚卸、変更履歴を提供	レビューの有効性を評価
変更管理	会計・決算・開示影響を確認	変更申請、テスト、リリースを管理	重要変更の統制運用を評価
データ連携	連携結果の会計影響を確認	連携仕様、エラー処理、ログを説明	インターフェース統制を評価
証跡保存	監査・決算で必要な証跡を指定	ログ・履歴の取得可能性を確認	証跡の十分性を評価
不備対応	財務報告影響と是正方針を検討	技術的原因と改善策を実行	不備評価、再評価、報告を実施
監査法人対応	質問意図を整理し回答を統括	技術的説明と証跡を提供	評価調書・評価結果を説明

この表は、会社ごとの組織体制に応じて調整すべきものです。ただしいずれの場合も、「誰かがやっているはず」という状態を残さないことが重要です。

相談前に整理しておきたいチェックポイント

IT部門・経理部門・内部監査の連携について専門家に相談する前に、次の項目を整理しておくと、論点が明確になります。

確認項目	整理する内容
システム一覧	財務報告に関係するシステム、SaaS、Excel、RPA、BI等
業務フロー	販売、購買、在庫、人件費、資金、決算・開示との関係
データ連携	どのシステムからどのシステムへ、何を、いつ連携しているか
権限管理	管理者権限、承認権限、マスタ変更権限、退職者削除
変更管理	重要変更の申請、承認、テスト、リリース、会計影響確認
証跡	承認履歴、ログ、帳票、照合記録、変更履歴の保存状況
RCM	IT依存統制、自動統制、IT全般統制との関係
内部監査	評価者、評価範囲、調書、レビュー体制、不備管理
監査法人指摘	過年度指摘、追加依頼、未解決論点、協議メモ
体制上の制約	兼務、少人数、外部委託、クラウド利用、子会社管理

この整理ができると、相談は「IT統制が不安です」という抽象的な話ではなくなります。「このシステム、この業務フロー、この統制を、どの部門がどう説明するか」という具体的な検討へ進むことができます。

IT統制の連携は、決算早期化と経営管理にも効く

IT部門・経理部門・内部監査の連携は、J-SOX評価のためだけのものではありません。

財務報告に関係するシステム・データ・業務フロー・証跡が整理されると、決算早期化や経営管理にも効果が及びます。

たとえば、システム台帳と業務フローが整えば、決算時にどのデータをどこから取得すべきかが明確になります。アクセス権限と承認ルートが整えば、権限移譲が進みます。データ連携とエラー処理が整理されれば、手作業の照合や修正が減ります。ログや承認履歴が整えば、監査対応の手戻りが減ります。

決算早期化を実現している会社では、単体決算、連結決算、開示業務を分断して見るのではなく、最終成果物から逆算して業務を組み立てる「森を見る視点」が重要になります。

J-SOX上のIT統制も同じです。アクセス権限、変更管理、ログ、システム台帳といった個別論点だけを見ていては、全体が見えません。

最終的な財務報告・開示・経営判断にどのデータが使われ、そのデータをどの統制が支えているのか。それを部門横断で説明できる状態にしておく必要があります。

IT部門・経理部門・内部監査の連携で専門家に相談すべき場面

次のような状況がある場合、社内だけで整理しようとすると、判断が属人化し、監査法人対応で手戻りが起こりやすくなります。

• IT統制が情報システム部門任せになっている
• 経理部門がシステム処理やログを十分に説明できない
• 内部監査部門がIT統制の評価手続を設計できない
• 財務報告に関係するシステム台帳が整備されていない
• 業務フローとシステム処理が対応していない
• IT依存統制や自動統制がRCMに反映されていない
• アクセス権限レビューが在籍確認だけで終わっている
• システム変更の会計影響を確認する仕組みがない
• 運用評価時にログや承認履歴が取得できない
• 監査法人からIT統制に関する追加依頼や指摘が続いている
• IPO準備やM&A後の統合に向けて、IT・経理・内部監査の連携体制を整えたい

犬飼公認会計士・税理士事務所では、J-SOX対応を、単なる文書化や評価調書の作成としてではなく、決算・開示・業務プロセス・IT・証跡・内部監査をつなぎ、会社が自ら説明できる管理体制を整える取り組みとして支援しています。

IT部門、経理部門、内部監査部門の役割分担を整理し、システム台帳、業務フロー、RCM、評価資料、監査法人対応の全体像を見直したい場合は、犬飼公認会計士・税理士事務所HPのお問い合わせページよりご相談ください。

出典・参考情報

出典：金融庁｜財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）
出典：金融庁｜「内部統制報告制度に関するQ&A」等の改訂について
出典：金融庁｜内部統制報告制度に関するQ&A
出典：経済産業省｜システム監査制度について
出典：経済産業省｜システム管理基準 追補版（財務報告に係るIT統制ガイダンス）
出典：日本公認会計士協会｜監査基準報告書315実務ガイダンス第1号 ITの利用の理解並びにITの利用から生じるリスクの識別と評価に関する実務ガイダンス

重要事項の振り返り

論点	実務上のポイント
IT統制の本質	IT部門の管理業務ではなく、財務報告に使われるシステム・データ・証跡を説明する仕組みである
IT部門の役割	システム構成、権限、変更管理、運用管理、ログ、データ連携を説明する
経理部門の役割	財務報告リスク、重要勘定、会計処理、決算・開示影響、監査法人対応を整理する
内部監査の役割	独立性を保ちつつ、整備評価・運用評価・不備評価を行い、改善を促す
システム台帳	IT資産一覧ではなく、業務プロセス・勘定科目・財務報告リスクと結びつける
業務フロー	取引発生から会計処理・証跡までの流れに、システム処理と統制点を組み込む
IT依存統制	人のレビュー統制でも、システム帳票・ログ・データに依存していればITの信頼性確認が必要になる
変更管理	IT部門の承認だけでなく、経理部門による会計・決算・開示影響の確認が必要になる
監査法人対応	経理部門が質問意図を翻訳し、IT部門の技術説明を財務報告リスクに結びつける
継続運用	年1回の資料更新ではなく、システム変更・業務変更・評価結果を期中で共有する仕組みが必要になる