「IT内部統制に対応してください」——経営企画や監査部門からそう求められたとき、情シス担当者として何をすればいいのか、すぐにイメージできるでしょうか。内部統制という言葉は耳にするものの、「具体的に何をすればよいのか」「情シスはどこまで関わればよいのか」という点が曖昧なままになっているケースは少なくありません。

IT内部統制は、上場企業が財務報告の信頼性を確保するために義務付けられている仕組みですが、その実務の多くは情シス部門が担います。アクセス権の管理、変更管理、システムの稼働維持、バックアップの確保——こうした日々の業務がIT内部統制の実態です。

この記事では、IT内部統制の基本的な概念から、J-SOXへの対応実務、SaaS時代における新たな課題と対策まで、情シスが理解しておくべき内容を体系的に解説します。

IT内部統制とは何か

IT内部統制の定義と、その目的を整理します。「なぜ情シスがやるのか」という問いへの答えを明確にするために、まず内部統制全体の枠組みから理解することが大切です。

内部統制とIT統制の関係

内部統制とは、企業が業務を適切に遂行するための仕組みです。財務報告の信頼性確保、業務の有効性・効率性の向上、法令遵守、資産の保全——この4つが内部統制の目的として定められています。

その中でIT統制（IT内部統制）とは、企業の内部統制のうち、ITに関わる部分を指します。現代の企業活動の多くはITシステムに依存しているため、ITが適切に管理・運用されているかどうかは、内部統制全体の有効性を左右する重要な要素です。

IT全般統制（ITGC: IT General Controls）ITの利用環境全体を適切に管理するための統制です。システムの開発・変更管理、アクセス管理、コンピュータ運用管理、外部委託管理が主な対象です。「業務処理統制が正しく機能するための土台」を整備するものと理解できます。

IT業務処理統制（ITAC: IT Application Controls）個々の業務システム（会計システム、販売管理システムなど）において、データが正確に処理・記録されることを確保するための統制です。入力データの検証、処理の正確性確認、出力データの完全性確認などが対象です。

情シスが主に担うのはIT全般統制です。IT業務処理統制は業務部門と連携して整備することが多く、情シスは技術的な側面（システム設定・ログ管理等）でサポートする役割を担います。

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

日本では、2008年度から金融商品取引法（J-SOX）の施行に伴い、上場企業には「財務報告に係る内部統制の評価・報告」が義務付けられています。IT全般統制はその重要な構成要素として、毎年の監査対象になります。

IT内部統制が不十分であると、財務データの改ざん・誤謬のリスクが高まり、監査での指摘事項（重要な欠陥・不備）となる可能性があります。これは企業の信頼性に直結する問題です。

上場企業だけでなく、ISMSの認証取得を目指す企業、取引先から内部統制の整備を求められている企業でも、IT内部統制への対応が必要になるケースが増えています。また、近年はIPO（株式上場）を準備する企業が上場審査の過程でIT内部統制の整備を求められるケースも多く、上場前から計画的に取り組む必要があります。

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

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

IT全般統制は、4つの管理領域で構成されます。それぞれの内容と、情シスが実施すべき具体的な対応を解説します。4つの管理領域は相互に関連しており、どれか一つが欠けても全体の統制が弱まります。

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

アクセス管理は、ITシステムへのアクセス権が適切に付与・管理されていることを確保する統制です。情シスにとって最も馴染み深い領域でもあります。監査では最も頻繁に指摘を受ける領域でもあるため、証跡の整備が特に重要です。

確認すべき事項

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

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

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

アクセス権限 棚卸し 方法

管理領域2: 変更管理

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

確認すべき事項

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

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

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

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

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

確認すべき事項

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

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

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

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

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

確認すべき事項

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

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

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

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

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

上場企業が取り組むJ-SOX対応において、IT内部統制はどのように評価されるかを解説します。監査の観点から「何を整備すれば合格できるか」ではなく、「なぜその統制が必要なのか」を理解することが、形骸化しない体制づくりの前提です。

評価のプロセス

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

1. 文書化: 業務プロセスとITシステムの関係を整理し、統制の文書化（フローチャート・RCM（リスクコントロールマトリクス））を行う
2. 整備評価: 文書化された統制が設計上有効かを評価する
3. 運用評価: 実際に統制が運用されているかをサンプルテストで評価する
4. 評価報告: 有効性の評価結果を内部統制報告書として開示する

IT全般統制の評価は、外部監査人（公認会計士）が行います。IT全般統制に重要な不備（Material Weakness）が発見された場合、財務報告全体の信頼性に疑義が生じ、監査意見に影響する可能性があります。

監査対応において情シスが実務的に関わるのは、主に「証跡の提出」です。「アクセス権レビューをいつ実施したか」「変更管理の承認はどのように行われたか」「バックアップの実施記録はどこにあるか」という監査人からの質問に、速やかに証跡で答えられる体制を整えておく必要があります。

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

アクセス管理の証跡: 退職者アカウントの削除タイミング、特権IDの利用記録、アクセス権レビューの実施記録など、アクセス管理に関する証跡の保管が監査で必ず確認されます。特に「退職者のアカウントが退職日から何日以内に削除されたか」は、監査でほぼ確実に確認される項目です。

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

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

経営者評価と外部監査の違い: 企業が自ら実施する「経営者評価」と、会計監査人が実施する「外部監査」は別物です。経営者評価でNGが出ていても、翌期までに改善すれば外部監査の指摘は回避できる場合があります。監査法人との事前コミュニケーションで、改善計画を共有しながら進めることが現実的です。

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

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

従来のIT内部統制の枠組みは、オンプレミスのシステムを前提に設計されています。SaaSが主流になった今、従来のアプローチでは対応しきれない新たな課題が生まれています。情シス担当者が「昔のやり方」に固執すると、実効性のない統制になるリスクがあります。

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

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

SaaSスプロールとは

特に問題なのが、情シスが把握していないシャドーIT（未承認SaaS）の存在です。把握していないSaaSには、IT内部統制の網がかかりません。シャドーITの発見と管理体制への組み込みが、SaaS時代のIT内部統制の前提条件です。J-SOXの観点では、「財務データに関連するSaaSを網羅的に把握できているか」が問われるため、会計システムに連携するSaaSや財務関連データを扱うSaaSを中心に優先的に管理対象を確定させる必要があります。

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

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

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

特に問題が起きやすいのが「異動時のアクセス権の適切な更新」です。部署異動・役職変更に伴うアクセス権の変更（前部署の権限削除＋新部署の権限付与）は見落とされがちです。異動のたびにアクセス権が積み上がる「権限のクリープ」は、IT内部統制の観点から重大な問題です。

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

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

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

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

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

IT内部統制を実効性のある形で整備・運用するための具体的なアクションを示します。「監査に通ること」ではなく「実際にリスクをコントロールすること」を目的として取り組むことで、形骸化しない統制が実現します。

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

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

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

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

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

[内部リンク: アクセス権限 棚卸し 方法]

アクセス権の棚卸しは、IT全般統制の中で最も監査で問われる領域のひとつです。年1〜2回の定期棚卸しを実施し、結果（変更・削除した権限の記録）を保管します。

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

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

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

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

退社 IT管理 手順

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

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

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

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

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

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

監査対応として、以下の証跡を一元的に保管・管理できる体制を整えます。

• アクセス権レビューの実施記録（実施日・確認範囲・変更内容・承認者）
• 変更申請・承認記録（申請者・承認者・変更内容・実施日・確認結果）
• 特権ID利用ログ（利用者・利用日時・実施した操作）
• バックアップ実施記録（実施日時・対象範囲・実施者・リストアテスト結果）
• インシデント対応記録（発生日時・内容・対応者・復旧日時・再発防止策）

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

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

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

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

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

ジョーシスがIT内部統制の実務を支援する方法

SaaS時代のIT内部統制において、ジョーシスはどのような支援を提供できるかを解説します。特に「管理対象のSaaSが多すぎて手作業では追いつかない」という課題を持つ企業に対して、ジョーシスは実務的な解決策を提供します。

SaaS利用状況の自動可視化

ジョーシスは、社内で利用されているすべてのSaaSを自動検出・可視化するプラットフォームです。情シスが把握していないシャドーITも含めて、社内SaaSの全容を一覧で確認できます。

IT内部統制の観点では、「管理対象のSaaSが網羅されている」という状態を維持することが前提条件です。ジョーシスの継続的な監視機能により、新しいSaaSが社内で使われ始めた際にアラートで通知を受け取ることができます。

J-SOX対応として特に有効なのが、ジョーシスによる「財務関連SaaSの優先管理」機能です。会計システムや販売管理システムに連携するSaaSをタグ付けして優先管理対象に設定し、それらのアクセス権変更・アカウント状況を重点的にモニタリングすることで、監査で問われる財務系統制への対応が効率化されます。

アクセス権管理の効率化

ジョーシスは、各SaaSのアカウント情報を一元管理し、人事データとの突き合わせによって退職者・異動者のアカウントを自動検出します。アクセス権の棚卸し作業を手作業ではなくダッシュボード上で完結できるため、作業工数を大幅に削減しながら証跡も自動保管できます。

入退社時のプロビジョニング・デプロビジョニングの自動化機能により、退職日にすべてのSaaSアカウントを自動削除する体制を実現します。これにより、J-SOX監査で問われる「退職者アカウントの適時削除」への対応が確実になります。

異動時のアクセス権変更についても、人事システムから異動情報を取得して前部署の権限削除・新部署の権限付与を自動実行する機能により、「権限のクリープ」を防止できます。

監査対応レポートの生成

ジョーシスでは、アクセス権の変更履歴、アカウントの付与・削除記録、SaaSの利用ログを自動保管します。監査時に必要なデータをダッシュボードから素早くエクスポートできるため、監査対応の準備工数を大幅に削減できます。

監査人から「直近1年間の退職者アカウント削除記録を提出してください」と求められた場合、ジョーシスを活用していれば数分以内にエクスポートして提出できます。手作業で記録を管理している場合、この作業に数日かかることもあります。

SaaS管理とは

IT内部統制は、一度整備すれば完了というものではありません。SaaSの増加、組織の変化、規制の改訂——こうした変化に合わせて、継続的に見直しと改善を行うことが求められます。

情シスがIT内部統制の実務を主導し、監査部門・経営企画と連携しながら体制を整えていくことが、企業全体のガバナンス強化につながります。SaaS管理ツールを活用して自動化できる部分は自動化し、限られたリソースを本当に必要な判断業務に集中させることが、現実的な対応策です。手作業の限界を超えて確実な統制を維持するために、ツールの活用は現代のIT内部統制において必要な選択です。