コトラ（広報チーム） 
IT監査は、企業や組織で利用されているシステム、データ、ITの運用体制が、ルールに沿って安全かつ適切に機能しているかを確認する取り組みです。情報システム部門だけの仕事ではなく、経営層、業務部門、内部監査部門、外部の専門家などが役割を分担しながら進めます。
本記事では、IT監査を初めて担当する方に向けて、目的、主な確認項目、関連する監査との違い、実施手順、準備のポイントをわかりやすく解説します。
IT監査とは
IT監査の基本的な考え方
IT監査とは、ITに関するリスクへの対応や管理の仕組みが適切かどうかを、一定の基準に基づいて確認・評価し、改善につなげる活動です。ITに関する監査を広く表す言葉として使われ、システム監査、情報セキュリティ監査、J-SOXに関わるIT統制の評価などが含まれることがあります。
監査では、単にシステムの設定画面を見るだけではありません。ルールが定められているか、実際にそのルールどおり運用されているか、問題が起きた場合に報告・改善される仕組みがあるかまで確認します。
重要なのは、IT監査を「不備を探すためだけの活動」と捉えないことです。監査の役割は、事実とリスクを明らかにし、組織がより安全で安定したIT環境を継続的に整えることを支援する点にあります。
IT監査が必要になる背景
企業活動では、会計、人事、販売、顧客管理、契約、コミュニケーションなど、多くの業務がシステムやクラウドサービスに支えられています。ITが止まったり、データが書き換えられたり、権限のない人が情報を持ち出したりすると、業務停止、情報漏えい、信用低下、財務報告の誤りなどにつながるおそれがあります。
また、クラウドサービスや外部委託の利用が増えたことで、自社だけでは管理が完結しない場面も増えています。外部サービスを利用していても、利用企業には、自社の情報や業務を適切に管理する責任があります。
上場準備やJ-SOX対応、取引先からのセキュリティ確認、新システムの導入、重大な障害や情報漏えいの発生なども、IT監査を行うきっかけになります。
IT監査で確認する「仕組み」と「運用」
IT監査では、「仕組みがあるか」と「仕組みが実際に使われているか」を分けて確認します。
仕組みとは、規程、手順書、責任者、承認の流れ、システム設定、記録の保存方法などです。たとえば、退職者のアカウントを削除するルールや、システム変更時に承認を得る手順が定められているかを確認します。
一方、運用とは、定めた仕組みが日常業務で守られている状態です。たとえば、退職日までに実際にアカウントが停止されているか、変更前の承認やテストの記録が残っているかを確認します。
文書だけが整っていても、実際の運用と異なっていれば十分とはいえません。反対に、現場で適切な対応をしていても、記録や証跡が残っていなければ、後から実施したことを説明しにくくなります。
IT監査が対象とする組織・システム・データ
IT監査の対象は、監査の目的とリスクに応じて決まります。すべてのシステムを同じ深さで確認するのではなく、事業への影響が大きいものや、重要な情報を扱うものを優先することが基本です。
対象には、次のようなものがあります。
- 基幹システム、会計システム、販売管理システム、人事システム
- クラウドサービスやSaaS
- サーバー、ネットワーク、データベース、端末
- 顧客情報、従業員情報、契約情報、会計データなどの重要データ
- IT部門、業務部門、委託先を含む管理体制
- システムの企画、開発、変更、運用、保守、廃止の手続き
監査対象を決める際は、「停止するとどの業務に影響するか」「漏えいするとどのような損害があるか」「財務報告に影響するか」といった観点で優先順位をつけます。
IT監査を行う目的と得られる効果
システムの安全性と信頼性を確かめる
IT監査の大きな目的は、システムが安全に利用でき、必要なときに安定して使える状態にあるかを確認することです。具体的には、利用者の権限、データの保護、バックアップ、障害対応、変更管理などを確認します。
また、業務で扱うデータが正確であり、意図しない変更や削除が起きにくい状態になっているかも重要です。特に会計や販売管理など、経営判断や財務報告に影響するシステムでは、データの正確性と完全性が求められます。
情報漏えい・不正利用・障害のリスクを減らす
IT監査は、情報漏えい、不正アクセス、内部不正、誤操作、システム停止などのリスクを早期に見つけるために役立ちます。
たとえば、退職者のアカウントが残っている、管理者権限を持つ人が多すぎる、共有アカウントを使っている、バックアップは取得しているが復旧確認をしていないといった状態は、重大な問題につながるおそれがあります。
監査を通じてこうした課題を洗い出し、優先度をつけて改善することで、事故の発生確率や被害の大きさを抑えられます。
業務がルールどおりに行われているか確認する
ITの管理では、ルールを作るだけでは十分ではありません。アカウントの追加・変更・削除、システム変更、障害対応、委託先の確認などが、決めた手順に沿って行われている必要があります。
IT監査では、担当者への聞き取り、申請書、承認記録、変更履歴、ログ、チケットなどを確認し、実際の運用を確かめます。これにより、属人的な作業や手続きの抜け漏れを発見しやすくなります。
業務の実態に合わない複雑なルールは、形だけの運用になりがちです。監査結果を活用して、現場で無理なく続けられる手順へ見直すことも重要です。
経営判断や法令対応に役立てる
ITリスクは、情報システム部門だけで完結する問題ではありません。重大なサイバー攻撃、基幹システムの停止、外部委託先での事故などは、事業継続や企業価値に大きな影響を与えます。
IT監査の結果を経営層や取締役会などへ報告することで、必要な投資、管理体制の見直し、リスクの受容判断などに役立てられます。
また、上場企業では、財務報告に係る内部統制報告制度であるJ-SOXへの対応が必要です。J-SOXにおけるIT統制の評価は、財務報告の信頼性に関係する範囲を対象とします。IT監査は、J-SOX対応だけではカバーしきれない情報セキュリティ、事業継続、委託先管理などの領域も含め、より広い視点で活用できます。
IT監査と関連する監査・取り組みの違い
IT監査とシステム監査の違い
IT監査とシステム監査には、法令上の明確で統一された使い分けがあるわけではありません。実務では、ほぼ同じ意味で使われることもあります。
一般的には、IT監査はITに関する監査活動全体を広く指す言葉です。一方、システム監査は、情報システムやその管理が、組織の目標達成に役立ち、安全かつ適切に運用されているかを独立した立場で評価する活動として位置づけられます。
名称だけで判断するのではなく、監査の目的、対象、評価基準、実施者、報告先を確認することが重要です。
IT監査と情報セキュリティ監査の違い
情報セキュリティ監査は、IT監査のうち、情報を守る仕組みに重点を置く監査です。情報の機密性、完全性、可用性が保たれているかを主な観点とします。
確認対象には、アクセス制御、多要素認証、脆弱性への対応、ログ管理、端末管理、インシデント対応、バックアップ、委託先のセキュリティ管理などがあります。
IT監査は情報セキュリティに加え、システム開発、変更管理、IT投資、ITガバナンス、財務報告に関わる統制なども対象にできます。情報セキュリティ監査は、IT監査の中でもセキュリティリスクに焦点を当てた取り組みと考えると理解しやすいでしょう。
IT監査と内部監査の違い
内部監査は、組織内の監査部門などが、業務、会計、法令遵守、リスク管理、内部統制などを独立した立場で評価する活動です。IT監査は、その内部監査のテーマの一つとして実施される場合があります。
たとえば、内部監査部門が販売業務の監査を行う際に、販売システムの権限管理やデータの変更管理も確認することがあります。また、ITに特化したテーマとして、クラウドサービス管理やサイバーセキュリティ対応を監査することもあります。
IT部門が自ら行う点検は重要ですが、IT監査では可能な限り、対象となる業務の運用者から独立した視点を確保することが望まれます。
IT監査と内部統制・J-SOXの関係
内部統制とは、業務の有効性と効率性、報告の信頼性、法令遵守、資産の保全を支える組織全体の仕組みです。IT統制は、その中でITに関わる部分を指します。
J-SOXは、金融商品取引法に基づく財務報告に係る内部統制報告制度です。上場会社の経営者は、財務報告に係る内部統制を整備・運用し、その有効性を評価して報告します。外部監査人は、経営者による評価結果を監査します。
J-SOXにおけるIT統制では、主に次の領域が確認されます。
- IT全社的統制：IT方針、責任体制、リスク管理、報告、監督などの全社的な仕組み
- IT全般統制：アクセス管理、システム変更管理、運用管理、外部委託管理など
- IT業務処理統制：入力チェック、自動計算、承認ワークフロー、データ照合などの業務システム上の統制
J-SOXの目的は財務報告の信頼性を確保することです。そのため、J-SOX対応ができていても、情報セキュリティやサイバー攻撃、事業継続に関するすべてのリスクをカバーできるわけではありません。
内部監査と外部監査の違い
内部監査は、組織内部の監査部門などが実施し、自社の業務や統制の改善を目的とします。経営者や取締役会、監査役などに報告し、改善状況の確認まで行うことが一般的です。
外部監査は、組織の外部にいる監査人や専門家が実施します。財務諸表監査に関わるIT監査、認証取得のための審査、取引先から求められる監査などが該当します。
外部の専門家を活用する場合でも、ITの管理や改善に関する最終的な責任は、組織の経営者や管理責任者にあります。
IT監査で確認する主な対象と監査項目
利用者アカウントとアクセス権限の管理
アクセス管理では、誰がどのシステムを利用できるか、どのような操作権限を持つかを確認します。特に、データの変更やユーザー管理ができる管理者権限は、必要最小限の人にだけ付与することが重要です。
主な確認項目は次のとおりです。
- アカウントの発行、変更、削除に承認手続きがあるか
- 入社、異動、退職に合わせて権限を適時に見直しているか
- 定期的なアカウント・権限の棚卸しを行っているか
- 管理者権限や特権IDが適切に管理されているか
- 共有アカウントを必要最小限にし、利用者を特定できる状態にしているか
- ログインや重要操作の記録を取得・保管しているか
特に退職者アカウントの停止漏れや、異動後も以前の部署の権限が残る状態は、リスクになりやすいため注意が必要です。
システム開発・変更時の管理
システムの機能追加、設定変更、プログラム修正、クラウドサービスの設定変更などは、誤操作や不正な変更を防ぐため、一定の手順に沿って実施する必要があります。
監査では、変更の目的、申請、承認、テスト、本番環境への反映、反映後の確認が記録されているかを確認します。緊急対応であっても、事後承認や記録を残すルールを設けておくことが重要です。
また、開発環境と本番環境を分け、開発担当者が無制限に本番環境を変更できない状態にすることも、重要な管理の一つです。
データの保管・バックアップ・復旧の仕組み
データ管理では、重要なデータが消失、破損、改ざん、漏えいした場合に備え、保管方法と復旧方法が整っているかを確認します。
バックアップは取得しているだけでは十分ではありません。実際に復元できるかを定期的に確認する復旧テストが必要です。復旧できなければ、障害やランサムウェア被害が発生した際に、事業の再開が遅れる可能性があります。
監査では、バックアップの対象、頻度、保管先、保管期間、復旧手順、復旧テストの記録などを確認します。
障害・不正・情報漏えいへの対応
システム障害、不正アクセス、マルウェア感染、情報漏えいなどが発生した場合、初動対応の速さと正確さが重要です。事前に対応手順、連絡体制、判断基準、報告先を明確にしておく必要があります。
確認項目には、次のようなものがあります。
- インシデント対応手順が文書化されているか
- 発生時に誰へ連絡し、誰が判断するか決まっているか
- 影響範囲の調査、復旧、再発防止の流れが定められているか
- 障害やインシデントの記録が残されているか
- 重要なログを必要な期間保管しているか
- 対応訓練や見直しを定期的に行っているか
ログは「誰が、いつ、何をしたか」を確認する重要な証拠です。取得対象、保管期間、閲覧権限、改ざん防止の方法を整理しておくことが求められます。
外部サービス・委託先の管理
クラウドサービス、SaaS、システム開発会社、運用委託先などを利用する場合、自社と委託先の責任範囲を明確にする必要があります。
確認する主なポイントは、契約内容、データの取り扱い、再委託の有無、障害時の対応、サービス終了時のデータ返却や削除、委託先のセキュリティ管理体制などです。
委託先が提供する第三者による統制報告書を確認できる場合は、報告対象期間、例外事項の有無、自社で対応すべき補完的な管理などを確認します。報告書がない場合でも、質問票、契約書、セキュリティに関する説明資料、定期的な報告などを通じて、リスクに応じた確認を行います。
IT監査の進め方
監査の目的・範囲・テーマを決める
最初に、なぜ監査を行うのかを明確にします。目的が曖昧なままでは、対象範囲や確認項目を決められません。
目的の例としては、情報漏えい対策の確認、クラウド利用管理の見直し、基幹システム更改後の確認、J-SOXに関わるIT統制の評価、外部委託先管理の点検などがあります。
目的を決めた後、対象部門、対象システム、対象期間、確認するリスク、評価基準、実施体制、日程を定めます。すべての領域を一度に監査しようとせず、重要度の高いテーマから着手することが現実的です。
リスクを整理して監査項目とチェックポイントを作る
監査項目は、一般的なチェックリストをそのまま使うのではなく、自社のリスクに合わせて作成します。
たとえば、顧客情報を扱うクラウドサービスであれば、アクセス権限、外部共有、ログ、委託先管理を重点的に確認します。自社開発の基幹システムであれば、変更管理、テスト、本番環境へのアクセス、バックアップ、障害対応が重要になります。
リスク、統制の目的、確認する内容、必要な証跡を対応づけて整理すると、監査の一貫性が高まります。
- リスク：退職者がシステムへアクセスし続ける
- 統制の目的：不要な利用権限を速やかに削除する
- 確認内容：退職連絡からアカウント停止までの手順と実施状況
- 証跡：退職者一覧、削除申請、アカウント停止記録、ログ
資料確認・聞き取り・現場確認を行う
本調査では、資料確認、担当者への聞き取り、システム画面や設定の確認、記録の抽出などを行います。
資料確認では、規程、手順書、組織図、システム構成図、アカウント一覧、変更記録、障害記録、契約書、過去の監査結果などを確認します。
聞き取りでは、文書だけでは分からない実際の運用を確認します。「ルールはあるが忙しいときは省略している」「担当者が不在のときの代替手順がない」といった課題が見つかることもあります。
現場確認では、必要に応じてシステム設定、ログ、チケット、バックアップ結果などを確認します。ただし、監査人が運用作業を代行したり、設定を変更したりしないよう、監査の独立性に配慮します。
監査証拠を整理して評価する
監査証拠とは、監査で確認した事実を裏付ける資料や記録です。規程、申請書、承認履歴、ログ、設定画面、インタビュー記録などが該当します。
評価では、「ルールがあるか」だけでなく、「ルールがリスクを抑える内容になっているか」「対象期間を通じて継続的に運用されているか」を確認します。
指摘事項をまとめる際は、単に「できていない」と記載するのではなく、事実、原因、想定される影響、改善の方向性を整理します。これにより、監査対象部門が対応の優先度を判断しやすくなります。
監査報告と改善計画の確認を行う
監査終了後は、監査結果を報告書にまとめ、関係部門や経営層へ報告します。報告書では、対象範囲、実施した手続き、確認した事実、評価結果、指摘事項、改善提案を明確にします。
指摘事項については、改善責任者、対応内容、完了期限、進捗確認の方法を定めます。重要なリスクが残る場合は、経営層が残存リスクを把握し、追加対策を取るか、一定のリスクを受け入れるかを判断する必要があります。
監査は報告書を出して終わりではありません。改善が実施され、実際にリスクが下がったかを確認するフォローアップまで含めて完結します。
IT監査を始める前の準備と実施時のポイント
監査の責任者・担当者・役割分担を明確にする
IT監査を円滑に進めるには、誰が監査を計画し、誰が証跡を準備し、誰が改善を実施するのかを明確にする必要があります。
一般的には、経営者が方針と責任体制を定め、業務部門とIT部門が統制を運用し、内部監査部門などが独立した立場から評価します。経営層や取締役会などは、重要なリスク、監査結果、改善状況について報告を受け、監督します。
少人数の組織では、運用者と評価者を完全に分けることが難しい場合があります。その場合でも、上長によるレビューや外部の専門家による確認などを活用し、できるだけ客観性を確保することが重要です。
規程・手順書・記録などの必要資料をそろえる
監査の直前に資料を探し始めると、担当者の負担が大きくなり、必要な証跡が見つからないおそれがあります。日常業務の中で記録を残し、保管場所を決めておくことが大切です。
代表的な準備資料は次のとおりです。
- IT関連の規程、セキュリティ方針、運用手順書
- 組織図、責任者一覧、システム構成図
- システム・クラウドサービス・委託先の一覧
- 利用者アカウント、権限、管理者権限の一覧
- アカウント発行・変更・削除の申請と承認記録
- システム変更の申請、承認、テスト、リリース記録
- バックアップ、復旧テスト、障害・インシデントの記録
- 委託契約、サービス仕様、委託先評価の記録
- 過去の監査報告書と改善状況
「誰が、いつ、何を実施し、誰が確認したか」を後から説明できる記録を残すことが、監査対応の基本です。
監査対象部門との日程・確認方法を調整する
監査では、対象部門の協力が欠かせません。監査開始前に、目的、対象範囲、確認方法、必要資料、担当者、日程を共有します。
特に、繁忙期に聞き取りや資料依頼が集中すると、現場の負担が増えます。事前に依頼事項を整理し、資料提出期限や面談時間を調整することで、監査品質と業務負担の両立を図れます。
監査対象部門に対しては、監査が責任追及だけを目的とするものではなく、リスクを把握して改善につなげる活動であることを説明することも重要です。
指摘だけで終わらせない改善提案のまとめ方
改善提案は、理想論だけでは実行されません。現場の業務量、システムの機能、予算、人員、委託先との契約などを考慮し、実現可能な方法を示す必要があります。
改善提案では、対応の優先度を分けると効果的です。
- 早急な対応が必要なもの：不正利用や情報漏えいにつながる重大な権限不備など
- 計画的に対応するもの：システム改修や運用体制の変更が必要な課題
- 継続的に改善するもの：手順書の更新、教育、定期点検の定着など
また、問題の原因が「担当者の注意不足」だけにあるとは限りません。ルールが複雑すぎる、承認者が不明確、ツール上で記録を残しにくい、人員が不足しているといった構造的な要因も確認し、再発しにくい仕組みづくりを目指します。
改善状況をフォローアップする
フォローアップでは、改善計画が期限どおりに進んでいるかだけでなく、改善後の運用が定着しているかを確認します。
たとえば、アカウント管理の手順を改定した場合は、改定後に発生した入退社や異動で、実際に新しい手順が使われているかを確認します。バックアップの改善であれば、取得記録だけでなく復旧テストの結果を確認します。
改善が遅れている場合は、理由、残るリスク、代替策、完了予定を明確にし、必要に応じて経営層へ報告します。監査、改善、フォローアップを繰り返すことで、ITガバナンスとリスク管理の成熟度を高められます。
IT監査を始める際は、すべてを一度に整えようとせず、重要なシステムと高いリスクの領域から着手することが重要です。まずは利用システム、重要データ、管理者権限、委託先、既存の記録を整理し、自社にとって優先すべき監査テーマを明確にしましょう。
