IT内部統制（IT統制）とは、企業の内部統制のうちITに関わる部分です。J-SOX対応では、財務報告に使うシステムが適切に管理され、処理の正確性を保てることを確認します。

情シスが主に担うIT全般統制（ITGC）は、アクセス管理・変更管理・コンピュータ運用管理・外部委託管理が対象です。ルールを定めるだけでなく、誰がいつ実施したかを証跡で説明できる状態に整えます。

IT内部統制とは何か

内部統制とIT統制の関係

内部統制は、報告の信頼性、業務の有効性・効率性、法令遵守、資産の保全を支える企業全体の仕組みです。そのうちITを対象とするIT統制は、IT全般統制とIT業務処理統制に分かれます。

実務に着手するなら、アクセス権限の棚卸し方法と管理台帳を確認すると、確認対象と記録の残し方を具体化できます。

経営層がIT戦略を方向付け・監督する仕組みはITガバナンスです。IT統制は、その方針を日々の管理へ落とし込みます。ITガバナンスの8つの構成要素と実践ステップで全体像を確認できます。

IT統制・情報統制・内部統制の違い

内部統制が企業全体、IT統制がそのIT領域、ITGC・ITACがIT統制の内訳という関係です。「情報統制」はIT統制の同義語として扱わず、監査や社内規程では「IT統制」「IT全般統制」のどちらを指すか確認してください。

情報セキュリティは機密性・完全性・可用性を守る活動です。対策を実施していても、手順の文書化や実施記録がなければ、IT統制の有効性を説明できないことがあります。

なぜIT内部統制が求められるか

日本では2008年度から、J-SOXに基づき上場企業に財務報告に係る内部統制の評価・報告が義務付けられています。IT内部統制が不十分だと、財務データの改ざんや誤謬のリスクにつながります。IPOを準備する企業でも、上場前から整備を進める必要があります。

金融庁は2023年4月に内部統制の基準・実施基準の改訂を公表し、2024年4月1日以後に開始する事業年度から適用しています。内部統制の目的は「財務報告の信頼性」から「報告の信頼性」へと整理され、ITの委託業務に係る統制の重要性も明示されました。

J-SOX以外の規制対応との関係は、ITコンプライアンスの規制対応と実践ステップで整理しています。

参考: 内部統制のひとつであるIT統制とは？重要性や分類・担当部門を紹介

参考: 金融庁「財務報告に係る内部統制の評価及び監査の基準・実施基準の改訂について」（2023年4月）

IT全般統制（ITGC）の4つの管理領域

ITGCの実務は、管理対象と残す証跡を対応させると整理できます。

SaaSの利用状況やアクセス権をまとめて管理する方法を検討している方は、「5分でわかるJosys」で製品概要を確認すると、支援範囲を把握できます。ITGC全体の統制設計は、社内の運用ルールと合わせて進めます。

管理領域1: アクセス管理

アクセス管理は、ITシステムへのアクセス権が適切に付与・管理されていることを確保する統制です。権限の必要性と、変更・削除の実施記録を確認します。

確認すべき事項

• ユーザーアカウントは業務上必要な権限のみが付与されているか（最小権限の原則）
• 退職・異動・休職に伴うアクセス権の変更・削除が適時に行われているか
• 管理者権限（特権ID）は必要最小限の担当者にのみ付与されているか
• アクセス権の定期的なレビュー（棚卸し）が実施されているか
• 共有アカウントが使用されていないか

情シスの対応実務: アクセス権の棚卸しを最低でも年1回実施し、業務上不要な権限を削除する作業が基本です。退職者のアカウント削除については、退職日当日または翌営業日以内に対応するプロセスを確立します。棚卸し結果（確認した日時・対象範囲・変更した権限の詳細）は、監査証跡として保管します。

特権IDの管理は厳格に行い、利用時のログを記録・保管します。共有アカウント（複数人が同じIDを使う形式）は廃止し、個人単位のアカウント管理に移行することが求められます。特権IDを日常業務で使用している担当者がいる場合、通常業務用の一般アカウントと特権操作用のアカウントを分離する「最小特権の徹底」も求められます。

棚卸しを滞らせないためには、レビューの単位と承認者を作業前に決めておくことが有効です。どのアカウント群を誰が確認し、どの記録を残すのかを定義してから着手すると、証跡の粒度が揃い、監査人からの追加質問も減ります。レビューの進め方と自動化の考え方は次の記事で詳しく整理しています。アクセス権レビューの実施方法と自動化

関連記事：アクセス権限の棚卸し方法（J-SOX・ISMS対応）

管理領域2: 変更管理

変更管理は、ITシステムへの変更（プログラムの修正、設定変更など）が適切な承認プロセスを経て実施されることを確保する統制です。財務関連システムへの不正な変更が財務報告の信頼性を損なうリスクを防ぎます。

確認すべき事項

• システム変更は承認された手順に従って行われているか
• 開発環境と本番環境が分離されているか
• 変更の記録（変更履歴）が保管されているか
• 緊急変更の際も事後承認など適切なプロセスが踏まれているか
• 変更実施後の動作確認・テストが記録されているか

情シスの対応実務は、変更管理台帳に「誰が、何を、いつ行ったか」を残すことです。

緊急変更も記録し、事後承認の手順を定めます。

‍

‍

情シスの対応実務変更管理台帳を整備し、すべてのシステム変更を記録します。変更申請→承認→テスト→本番反映という標準的なワークフローを文書化し、実際の変更作業が手順通りに行われていることを確認します。

SaaSの設定変更も、変更管理の対象に含まれることに注意が必要です。重要なSaaSの設定を変更する際は、承認記録を残す習慣をつけることが求められます。特に、認証設定（MFA要件の変更・SSO連携の追加削除）やアクセス権限のグローバル設定変更は、財務データに影響する可能性があるため、変更管理の対象として明示的に定義しておくことが重要です。

管理領域3: コンピュータ運用管理

コンピュータ運用管理は、ITシステムが安定して稼働するための日常的な管理が適切に行われていることを確保する統制です。バッチ処理の正常実行や障害時の迅速な対応が、財務データの正確性に影響します。

確認すべき事項

• バックアップが定期的に取得・確認されているか
• ジョブ（バッチ処理）の実行状況がモニタリングされているか
• システム障害時の対応手順が文書化されているか
• セキュリティパッチ・アップデートが適時に適用されているか
• システムの稼働状況（可用性・パフォーマンス）が定期的に監視されているか

情シスの対応実務バックアップの実施記録と、定期的なリストアテストの実施記録を保管します。ジョブ管理ツールを使ってバッチ処理の正常終了を自動確認し、異常終了時のアラート通知を設定します。

SaaSを多数活用している場合は、SaaS提供会社のシステム稼働状況の確認方法（ステータスページ等）も整理しておきます。SaaSの障害が発生した際に、その影響範囲・発生時刻・復旧時刻を記録しておくことが、運用管理の証跡として機能します。主要なSaaSのステータスページをブックマークし、定期的に確認する習慣をつけることが推奨されます。

管理領域4: 外部委託管理

外部委託管理は、ITシステムの開発・運用を外部に委託している場合の管理が適切に行われていることを確保する統制です。SaaSが主流になった現在、ほぼすべての企業がシステムの一部を外部委託（SaaSベンダーへの委託）している状態です。

確認すべき事項

• 委託先のセキュリティ管理体制が自社要件を満たしているか
• 委託契約にデータ管理・セキュリティに関する条項が含まれているか
• 委託先の内部統制の状況を定期的に確認しているか（SOCレポートの取得など）
• データの所在・処理場所が明確になっているか（国外データ処理の可否等）

情シスの対応実務: 主要なSaaSベンダーのSOC2 Type2レポートを取得・確認し、監査証跡として保管します。新規SaaS導入時のセキュリティ評価プロセスを定め、評価結果を記録します。

SOC2レポートの取得が難しいベンダー（主に国内の中小SaaSベンダー等）については、セキュリティアンケートの実施や契約書へのセキュリティ要件の明記で代替します。重要度が低いSaaSについては、ベンダーのウェブサイトで公開されているセキュリティホワイトペーパーや認証取得状況（ISMSなど）の確認で足りる場合もあります。リスクレベルに応じた確認深度の設計が、工数削減と実効性のバランスを取る鍵です。

取引先から自社のセキュリティ対策水準を確認される場面では、SCS評価制度との関係も押さえておきます。経済産業省・内閣官房国家サイバー統括室が2026年3月に制度構築方針を公表し、運営はIPAが担います。★3は専門家確認付き自己評価、★4は第三者評価という位置づけです。

SCS評価制度は任意の制度で、J-SOXとは別の枠組みです。特定の製品を導入すれば要件を満たせるわけではありません。規程と運用記録を揃え、それぞれの制度で必要な証跡を確認します。

参考: IT統制の目的とポイント。内部統制基準の改訂による影響とは

参考: サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度） | IPA

J-SOX対応でIT内部統制に求められること

J-SOX対応では、統制の設計と実際の運用を証跡で説明します。情シスは内部監査部門と評価範囲を確認し、必要な記録を揃えます。

評価のプロセス

J-SOXの内部統制評価は、毎期次のプロセスで行われます。

企業が行う経営者評価と会計監査人による外部監査は区別します。情シスは「アクセス権レビューはいつ行ったか」「変更は誰が承認したか」「バックアップの記録はどこか」に、証跡で答えられる体制を整えます。

情シスが特に注意すべきポイント

アクセス管理の証跡: 退職者アカウントの削除タイミング、特権IDの利用記録、アクセス権レビューの実施記録を保管します。退職日と実際の削除日を記録し、対応時期を説明できるようにします。

変更管理の記録: 財務関連システムへの変更が、承認されたプロセスを経ていることの証跡（変更申請書・承認記録）が求められます。「誰が申請し、誰が承認し、誰が実施し、何を確認したか」という4点セットが揃っていることが重要です。

本番環境と開発環境の分離: 開発用のシステムと本番システムが同一環境で動いている状態は、変更管理の観点から問題視されます。小規模な企業では同一環境で運用しているケースがありますが、J-SOX対応では分離が求められるため、早期に対応を進める必要があります。

不備が見つかった場合は、監査法人と改善計画を共有しながら進めます。

証跡の提出を求められてから探し回る状況を避けるには、ログの取得設定と保管先を先に整えておくことが要点になります。SaaSごとに取得できるログの種類と保持期間が異なるため、統制上必要なログが実際に残っているかを一度棚卸ししておくと、監査時の手戻りを防げます。SaaSの監査ログの取り方と一元管理

参考: J-SOXのIT統制で企業が取るべき対応や対応時のポイントを解説

SaaS時代のIT内部統制の課題

SaaSごとに管理画面・権限・ログの保管先が分かれると、管理対象の把握と証跡収集に手間がかかります。特に、未承認SaaSと異動時の権限変更を確認します。

管理対象のSaaSが急増している

従業員500名以上の企業では、利用するSaaSが100種類を超えることが珍しくありません。それぞれのSaaSに対してアクセス管理・変更管理・外部委託管理を行う必要があるため、従来の手作業ベースのアプローチでは管理が追いつかなくなっています。

SaaSスプロールとは

シャドーITは、情シスが把握していない未承認SaaSです。把握できなければ統制の対象から漏れるため、財務データに関わるSaaSから管理対象を確認します。発見の手順はシャドーIT検出の方法で確認できます。

• 会計システムに連携するSaaSと財務関連データを扱うSaaSを洗い出す
• 利用者・管理者と付与されている権限を確認する
• 未承認SaaSを見つけたら、管理台帳と運用ルールへ組み込む

SaaSの把握や権限管理を自社でどう進めるか検討する方は、Josysのデモを予約し、管理対象SaaSと連携範囲を確認することができます。

管理対象が増えたときにどこで統制が詰まるかは、中堅企業でおおむね共通しています。人員が限られる中で優先順位をつけるための整理は次の記事にまとめています。中堅企業のIT統制の課題と解決策

アクセス管理が複雑化している

オンプレミス時代は、Active Directoryでアカウントを一元管理できていました。SaaSが増えた今は、各SaaSに独立したアカウント管理が存在し、それらを統合的に管理することが難しくなっています。

入退社時に全SaaSのアカウントを確実に処理するためには、人事データと各SaaSを連携させた自動化の仕組みが不可欠です。手作業での管理は、どうしても漏れや遅延が生じます。監査の観点では「退職者アカウントの削除遅延」が指摘事項になりやすく、50種類以上のSaaSを手作業で管理している企業では対応が追いつかないケースが増えています。

異動のたびに旧部署の権限が残り、必要以上の権限が積み上がる状態を「権限のクリープ」と呼びます。部署異動・役職変更の際は、次を確認します。

• 前部署で使っていた権限を削除したか
• 新部署で必要な権限だけを付与したか
• 確認者、実施日時、変更した権限を記録したか

SOC2レポートの確認工数が増加

外部委託管理として、主要SaaSベンダーのSOC2 Type2レポートを毎年確認する作業が求められますが、SaaSの数が増えるほど確認工数も増加します。重要度の高いSaaSを優先的に確認するリスクベースのアプローチが現実的です。

SOC2レポートの確認で確認すべき主なポイントは、「報告対象期間」「意見の種別（適正意見か限定意見か）」「例外事項の有無と内容」の3点です。レポート本文は数十ページに及ぶため、最初にこの3点を確認し、例外事項がある場合に詳細を読み込むという手順が効率的です。

参考: システム管理基準 追補版（財務報告に係るIT統制ガイダンス）

IT内部統制の整備・運用で情シスが取るべきアクション

統制の文書化から証跡の保管までを日常業務に組み込みます。担当者と実施記録を結び付けておくと、監査前に証跡を探し回る負担を抑えられます。

アクション1: 統制の文書化と定期更新

IT内部統制の整備評価に向けて、統制の文書化（手順書・フロー・RCM）を行います。文書化は「一度作れば終わり」ではなく、システム変更・体制変更があった際に定期的に更新することが必要です。

文書管理の責任者を明確にし、年1回の定期レビューをスケジュールに組み込むことで、形骸化を防げます。RCM（リスクコントロールマトリクス）では、「リスク→統制→証跡」の対応関係を明示することで、監査対応の際に「どの証跡がどのリスクを説明するか」が一目でわかる構造になります。

新任の情シス担当者が引き継ぎを受けた際でも、文書化された統制手順書があれば業務の継続性が保たれます。これは情シスの人員リスク管理の観点でも重要です。

アクション2: アクセス権棚卸しの定期実施

アクセス権の棚卸しは、IT全般統制の中で最も監査で問われる領域のひとつです。年1〜2回の定期棚卸しを実施し、結果（変更・削除した権限の記録）を保管します。具体的な手順と管理台帳の作り方はアクセス権限の棚卸し方法で解説しています。

棚卸しの実施方法として、実務的に機能しやすいのは「部署マネージャーによる承認方式」です。システム管理者が各SaaSのアカウント一覧を部署マネージャーに送り、「このユーザーは引き続きアクセス権が必要か」を承認してもらう形式で実施します。この方式では、情シスだけでは判断できない「業務上の必要性」をマネージャーが確認するため、統制の実効性が高まります。

棚卸し作業を効率化するために、SaaS管理ツールを活用してアカウント一覧を自動生成し、人事データとの突き合わせを自動化する仕組みを導入することで、工数を大幅に削減できます。

アクション3: 入退社時のプロセスの自動化

退職者アカウントの削除遅延は、J-SOX監査で指摘を受けやすいポイントです。人事データと連携した自動デプロビジョニングの仕組みを導入することで、退職日にアカウントが自動削除される体制を整備できます。

具体的な確認手順は退職者アカウント削除の方法で整理しています。

自動化の対象として優先すべきは、財務関連データにアクセスできるSaaS（会計システム・ERPなど）と、多くのデータを扱うSaaS（Google Workspace・Microsoft 365など）です。これらのSaaSでの退職者アカウント放置が最もリスクが高く、自動化のインパクトも大きいです。

自動化が難しいSaaSについては、「退職者対応チェックリスト」を整備し、手動での確認と削除作業を漏れなく実施できる仕組みを作ります。チェックリストへの確認者・日時の記録が証跡になります。

アクション4: 変更管理プロセスの標準化

IT内部統制では、変更管理のプロセスが「承認」「実施」「記録」の三段階で機能していることが求められます。変更申請システム（チケット管理ツールなど）を活用して、変更の申請・承認・記録が自動的に残る仕組みを作ります。

変更管理プロセスの整備において、特に見落とされがちなのが「SaaSの設定変更」です。オンプレミスのシステム変更は意識される一方、SaaS管理者画面での設定変更は個人的な操作として行われがちです。重要なSaaSの設定変更（SSO設定・MFA要件・データ保持期間設定など）は変更管理の対象として定義し、変更前の承認と変更後の記録を義務づけます。

アクション5: 証跡管理の体制整備

監査対応として、証跡と記録項目を対応させて保管します。

証跡ごとに記録責任者を決め、どのファイルのどの項目で監査人の質問に答えるかも整理します。

これらの証跡を都度探し回る状況を避けるため、保管場所と保管期間のルールを事前に定めておくことが重要です。J-SOXの観点では、証跡の保管期間は最低5年が推奨されます。証跡をクラウドのファイルサーバー（Google Drive・SharePointなど）で管理する場合、フォルダ構造と命名規則を統一することで検索性が向上します。

仕組みとして定着させるには、あと2点を決めておくと効果的です。1つは証跡ごとの記録責任者です。「誰が残すか」を割り当てておかないと、担当者の異動や繁忙期に記録が途切れます。もう1つは、監査人からの定番質問に対する回答経路の一覧です。「退職者アカウントはいつ削除されたか」「アクセス権レビューは誰が承認したか」という質問に対して、どのファイルのどの項目を見れば答えられるかを事前に整理しておくと、監査対応の所要時間が大きく変わります。

証跡は監査の直前に作れるものではありません。日常業務の出力がそのまま証跡になる状態を目標に、記録の形式を業務プロセス側へ埋め込んでおくことが、工数と品質の両面で有利になります。

アクション6: 情シスと内部監査・経営企画との連携体制

IT内部統制の整備は情シスだけでは完結しません。内部監査部門がIT全般統制の評価を担当することも多く、情シスと内部監査が年間スケジュールを共有しながら連携することが重要です。

具体的には、年度初めに「今期の監査スコープ（重点的に評価する統制領域）」を内部監査と確認し、それに向けた証跡収集・整備計画を情シス側で立てます。監査直前に慌てて証跡を集めるのではなく、日常の業務の中で自然に証跡が蓄積される仕組みを作ることが、IT内部統制の成熟度を高める鍵です。

参考: IT統制における情報システム部門の役割とは？

JosysがIT内部統制の実務を支援する方法

Josysは、AI駆動のアイデンティティセキュリティ基盤です。SaaS・デバイス・アクセス権限を一元管理し、IT内部統制のうち利用状況の把握や権限管理に関わる実務を支援します。統制の設計や承認、監査上の判断は、社内の担当部門と進めます。

SaaS利用状況の自動可視化

SaaS Discoveryは、ログイン・ブラウザ活動からSaaS利用状況を検出します。検出した情報を管理台帳と照合し、情シスが把握していなかったSaaSを管理対象として確認する作業に役立てます。財務データとの関係や管理の優先順位は、自社で判断します。

アクセス権管理の効率化

SaaS Insightsは統合アクセスインテリジェンスと自動ライセンスレビュー、Access Automationは入退社ライフサイクルの自動化を支援します。アカウントの付与・削除を自動化できるのは連携対象の範囲です。対応するSaaSと操作を確認し、対象外のサービスは手動のチェックリストで補います。

監査対応レポートの生成

監査に必要な記録を整理する際は、JosysのAccess Reviews（監査対応コンプライアンスサーベイ）の支援範囲を確認します。必要な証跡の種類・保管期間・出力方法と、自社の監査要件を照合してから運用を決めます。

Josysは国内外1,000社以上で導入されています。IT工数を最大50%、ITコストを最大75%削減した事例がありますが、個社の条件により効果は異なり、監査対応工数の削減率を示す数値ではありません。

SaaS管理とは

IT内部統制は、SaaSの増加や組織の変化に合わせて見直し続ける仕組みです。管理対象を把握し、権限・変更・運用の記録を日常業務に組み込むことから始めてください。