セキュリティ

システム監査とは?2023年改訂の基準12項目と委託先が用意する証跡を解説

アンケート管理システムの効果的な活用方法

システム監査は、監査人が一定の基準に照らして情報システムの管理状況を検証し、経営者などに保証や改善の助言を与える監査です。経済産業省のシステム監査基準は2023年4月26日に改訂され、基準の並びも、監査の手続を細かく示す文書の置き場所も変わりました。この記事では、システム監査とは何か、システム監査基準とシステム管理基準の役割分担、システム監査人を誰が務めるのか、そして監査の流れを原文にあたって整理します。後半では、開発や運用を外部に委託している組織が監査を受けるとき、委託先にどの記録を用意してもらえばよいかを、開発と運用のドキュメントに落として示します。

まとめ|システム監査で問われる点と委託先が先に整えておく記録の要点

システム監査は法令で義務付けられた監査ではありません。経営者や取締役会が「ITの管理が機能しているか確かめたい」「不備があるなら直し方を知りたい」と考えたときに、自ら依頼する任意の監査です。目的によって、結論を保証する保証型と、改善策を示す助言型に分かれます。

読むべき文書は2つです。監査人がどう振る舞うかを定めたシステム監査基準と、監査人が何を物差しに判断するかを定めたシステム管理基準で、どちらも2023年4月26日付の版が現行です。監査を受ける側が準備に使うのは後者で、特にITマネジメント編の管理項目が実務の対象になります。

結論を左右するのは、監査人が口頭説明ではなく書面や記録で確かめられるかどうかです。開発や運用を委託しているなら、変更の承認記録、構成の台帳、運用ログ、障害と対応の記録を、委託契約の段階で「誰がどの形式で残すか」まで決めておく。監査直前に書類を作り直す組織ほど、指摘事項が増えます。

システム監査とは何か・経済産業省の定義と保証型と助言型の二つの目的

似た名前の監査が多いため、何を対象に誰へ報告する監査なのかを原文で押さえます。

システム監査基準の定義文が示す監査の対象とITシステムという用語の範囲

システム監査基準(令和5年4月26日)は、システム監査を、専門性と客観性を備えた監査人が一定の基準に基づいてITシステムの利用に関わる検証と評価を行い、ガバナンス、マネジメント、コントロールの適切性について保証を与えるか、改善のための助言を行う監査だと定めています。

ここでいう「ITシステム」は、サーバーやアプリケーションだけを指しません。基準はIT、情報システム、データと情報をまとめた概念としてこの語を使っており、企画や調達、外部委託、設計、移行、運用、保守、廃棄の各工程に加え、外部のITサービスを調達して使う工程まで含めています。クラウドサービスの選定や委託先の管理も、監査の範囲に入るということです。

保証を目的とする監査と助言を目的とする監査で当事者と報告先が変わる

監査の性格は、保証型か助言型かで大きく変わります。保証型では、監査対象に関わるプロセス・オーナー、評価を行う監査人、結果を使う利用者の三者が当事者になり、範囲と内容を決めるのは監査人です。助言型では、監査人と依頼者の二者が当事者で、範囲は依頼者との合意で決まります。

区分 当事者 範囲を決める者 典型的な依頼の動機
保証型 プロセス・オーナー 監査人・利用者 監査人 管理が機能していることを確かめたい
助言型 監査人・依頼者 依頼者との合意 不備を指摘し改善策を示してほしい

基準3の解釈指針は、助言型で不備を洗い出し、成熟度が確認できた時点で保証型に進む順序を「通例」と書いています。初めての監査でいきなり保証型を選ぶと、指摘事項が並ぶだけで終わりかねません。管理の整備が途上なら、助言型から入るのが筋のよい選び方です。

内部監査・会計監査・情報セキュリティ監査とシステム監査の対象の違い

名前の似た監査は、対象と判断の物差しで区別できます。

監査 主な対象 判断の物差しの例 法令上の義務
システム監査 ITのガバナンス・管理・統制 システム管理基準 なし(任意)
情報セキュリティ監査 情報セキュリティの管理 情報セキュリティ管理基準 なし(任意)
内部監査 業務全般の有効性・準拠性 社内規程・内部監査基準 組織により異なる
会計監査 財務諸表の適正性 会計基準・監査基準 法定監査あり

システム監査は内部監査部門が担うことも多く、両者は重なります。違いは対象をITに絞り、IT固有の判断尺度を使う点です。情報セキュリティの領域を見るときは、システム管理基準とあわせて情報セキュリティ管理基準も参照するよう、監査基準の前文が求めています。ISOマネジメントシステムの規格適合を確かめる監査は性格が別で、手順はISO 19011:2026に沿ったISO内部監査の進め方で扱っています。

システム監査基準とシステム管理基準の役割分担と令和5年改訂の構成

システム監査の基準として経済産業省が公表している文書は2つあり、役割がはっきり分かれています。経済産業省のシステム監査制度のページで、両方の現行版と旧版が公開されています。

行為規範の監査基準と判断尺度の管理基準を取り違えないための読み分け

システム監査基準は、監査人の行為規範と監査手続のルールを定めた文書です。どんな体制で計画を立て、どう証拠を集め、どう報告するかが書かれています。監査を受ける側が読んでも、自社が何を整えればよいかは直接は分かりません。

受ける側が読むべきはシステム管理基準(令和5年4月26日改訂)です。監査人が判断の尺度に使う文書で、ITガバナンス編とITマネジメント編に分かれ、ITマネジメント編はⅡ.1の推進・管理体制からⅡ.10の人的資源管理まで、企画、開発、運用、保守、廃棄、外部サービス管理、事業継続管理を含む10の領域で構成されています。各項目に「達成目標」と「管理活動の例」が並ぶため、自社の状態と突き合わせる点検表として使えます。ITガバナンス編が定める取締役会等の役割と方針の項目は、ITガバナンスとは何かを定義から整理した記事で扱っています。

監査基準の前文は、組織の特性に応じて管理基準を調整した規程を判断尺度にしてもよいとしています。全項目を満たす前提の文書ではありません。

属性・実施・報告の3区分に並ぶ基準1から基準12の内容と読みどころ

令和5年版の監査基準は、前文、システム監査の意義と目的、監査人の倫理、システム監査の基準という並びです。倫理は誠実性、客観性、監査人としての能力及び正当な注意、秘密の保持の4原則で示されています。基準本体は12項目で、3つの区分に分かれます。

区分 基準 受ける側から見た読みどころ
属性 1 権限と責任等の明確化 外部委託時は契約書に権限と責任を記載
属性 2 専門的能力の保持と向上 監査テーマに合う知識を持つ監査人か
属性 3 ニーズの把握と品質の確保 任意監査なので目的を依頼側が決める
属性 4 独立性と客観性の保持 監査対象と同じ指揮系統の者は不可
属性 5 能力及び正当な注意と秘密の保持 提出資料の秘密保持
実施 6 監査計画の策定 リスク・アプローチで範囲を決める
実施 7 監査計画の種類 中長期・年度・個別の3層
実施 8 監査証拠の入手と評価 予備調査と本調査・書面の証拠
実施 9 監査調書の作成と保管 結論に至る過程の記録
実施 10 監査の結論の形成 残存リスクで指摘の要否を判断
報告 11 監査報告書の作成と報告 報告書の写しは監査対象先へ回付
報告 12 改善提案のフォローアップ 改善計画書と実施状況の報告

受ける側が特に読んでおきたいのは基準8と基準10です。基準8は何を証拠として求められるかを、基準10は不備のうちどれが指摘事項になるかを決めています。基準10の解釈指針は、発見した不備をすべて指摘事項にする必要はなく、残存リスクの大きさで優先順位を付けるとしています。一方で、キーコントロールが明らかに不十分な場合は、原則として指摘事項に該当するという扱いです。

改訂で新設されたガイドラインと日本システム監査人協会が担う実施手順

令和5年改訂のもう1つの変化は、文書の置き場所です。監査にとって普遍的な内容だけを基準に残し、実施方法のように環境の変化に合わせて更新が必要な内容は、民間団体が整備するガイドラインに移す体制に変わりました。改訂の背景としては、AIとDXの普及、サイバー攻撃の高度化、スリー・ラインズ・モデルで語られるモニタリング活動との連携、アジャイル型監査の普及などが挙げられています。

そのガイドラインは、特定非営利活動法人日本システム監査人協会がシステム監査・管理ガイドラインとして公開しています。着眼点や具体的な手続を知りたいときは、基準本文ではなくこちらを参照します。

システム監査人は誰が務めるのか・社内監査と外部委託の選び方と独立性

システム監査人は資格の名前ではなく、監査を行う立場を指す言葉です。基準は担い手を幅広く想定しています。

監査役等・内部監査人・外部の専門家という3つの担い手と依頼の経路

監査基準の前文によれば、監査人には会社法上の監査役(会)等とその補助使用人、内部監査人、組織の依頼を受けて監査する外部の第三者が含まれます。監査役(会)等の役割は、株主からの委任を受けて取締役の業務執行を監査する一環として、ITのガバナンスを監査することです。内部監査人と外部の監査人は、取締役会や経営者の委託を受けて監査を行います。

独立性の要件も見落とせません。基準4の解釈指針は、監査人の所属部門が監査対象と同じ指揮命令系統にある場合、組織的な独立性が損なわれている外観を呈すると注意しています。情報システム部門の部員が自部門のシステムを監査する形は、この要件に合いません。

外部委託時に契約書へ書く権限と責任・システム監査企業台帳の使い方

社内に適任者がいない、高度な技能が要る、遠隔地の拠点を見る必要があるといった場合は、監査の全部または一部を外部の専門家に委託します。基準1は、その際に委託する業務の内容と、受託する専門家の権限と責任を契約書などの文書に明記するよう求めています。委託しても監査の最終責任は依頼側の監査組織の長に残るという点も、同じ箇所にある記載です。

委託先を探す手がかりとして、経済産業省は「システム監査企業台帳」を公開しています。システム監査を行う企業が実績などを申告したもので、2026年10月時点で掲載されているのは令和8年度分のExcel形式の台帳です。台帳に載っていることは品質の保証ではないため、監査テーマに合う知識を持つ担当者がいるか(基準2)、自社と特別な利害関係がないか(基準1・基準4)を、見積もりの段階で確かめます。

監査計画から報告とフォローアップまでのシステム監査の流れと各段階の記録

監査の流れは、計画、予備調査、本調査、結論の形成、報告、フォローアップの順です。

リスク・アプローチで監査範囲を絞る中長期・年度・個別の3層の計画

基準6は、監査計画を主としてリスク・アプローチで策定するよう求めています。リスクの大きさを発生可能性と影響度の組み合わせで評価し、大きい領域に人員と時間を厚く割り当てる方法です。保証型の監査対象や優先度は、主に統制を施したあとも残る残存リスクの評価で決まります。

計画は基準7で、中長期計画、年度計画、個別監査計画の3層に分けます。中長期計画は情報システムの中長期計画やシステム更改の予定と整合させて作るものとされています。基幹システムの刷新を控えた年は、刷新プロジェクトそのものが監査対象に選ばれやすいということです。

予備調査と本調査で集める監査証拠と口頭説明だけでは足りない理由

基準8の解釈指針は、監査手続を予備調査と本調査に分けています。予備調査では、システムや業務の詳細、業務マニュアル、組織図などで監査対象の実態をつかみます。本調査で集めるのは、結論を裏付けるための十分かつ適切な監査証拠です。

受ける側が押さえるべきは、口頭説明だけでは証拠として足りないと明記されている点です。インタビューで聞いた内容を、書面の証拠、現物との照合、操作の観察、テスト、詳細な分析で裏付けることが求められます。使われる技法としては、チェックリスト法、ドキュメントレビュー法、インタビュー法、ウォークスルー法、突合・照合法、現地調査法、コンピュータ支援監査技法(CAAT)が挙げられています。

「承認してから本番に反映しています」と答えても、承認の記録が出せなければ証拠になりません。

監査調書・監査報告書・改善計画のフォローアップで残す記載事項

監査人は、実施した手続と入手した証拠、到達した結論を監査調書に残します(基準9)。結論は監査調書から論理的に導かれ、指摘事項にする前に監査対象先との事実確認が行われます(基準10)。意見交換会や監査講評会がその場です。

保証型の監査報告書には、監査の目的、対象範囲、実施期間、実施者を含む概要と、結論、指摘事項、改善提案や改善計画を含む結果を記載するのが望ましいとされています(基準11)。報告書の写しは監査対象先にも回付されます。

報告のあとは基準12により、監査人が改善計画書と改善実施状況報告書で進み具合を見守ります。改善を実行する責任は監査対象先にあり、監査人が改善計画の策定に関わることは独立性を損なうとされています。直す手を動かすのは自社か委託先です。

開発と運用を委託している組織が監査に備えて委託先と整える証跡の作り方

ここからは、開発や運用を外部に委託している組織の目線で扱います。基準3の解釈指針は、委託元が委託先の管理レベルを判断するために第三者評価を求めるニーズにも触れており、委託先の記録は監査の対象そのものになり得ます。

システム管理基準の管理項目を設計書・変更記録・運用ログに対応づける

システム管理基準の管理活動の例は、そのまま「どの記録があれば確かめられるか」に読み替えられます。開発と運用の主な項目を成果物に対応づけました。

管理基準の項目 管理活動の例(要旨) 証跡になる成果物
Ⅱ.2.6 外部委託管理 選定基準・契約・検収 委託先評価表・契約書・検収記録
Ⅱ.2.7 構成管理・変更管理 台帳の作成と最新化・承認後のリリース 構成管理台帳・変更申請と承認の記録
Ⅱ.2.9 ドキュメント管理 管理対象の明確化・改訂・保管・廃棄 文書一覧・版番号つきの設計書
Ⅱ.5.7 運用の監視と記録 稼動実績の記録・ログの取得と分析 監視記録・アクセスログ・分析結果
Ⅱ.6.6 実施結果の記録と報告 保守作業の結果を記録し報告 保守作業報告書・障害対応記録

表のうち優先度が高いのは、構成管理・変更管理と運用の監視と記録です。Ⅱ.2.7は、構成要素の変更が承認に基づいてリリースされていることと、管理台帳の内容が本番環境と一致しているかの検証を求めています。台帳はあるが更新が止まっている、という状態が最も見つかりやすい不備です。業務システムで操作ログをどこまで残すかは、ワークフローシステムで監査証跡に残すログ項目と保存年限で具体的に扱っています。

アジャイル開発で監査証拠が不足する場面とチケットとCI記録で補う方法

基準8の解釈指針は、アジャイル開発のようにドキュメント作成に重きを置かない手法では、作られるドキュメントの種類や時期が従来型と異なることを理解したうえで、手法に応じた証拠を入手するよう監査人に求めています。言い換えると、監査人は「設計書が無いから不備」とは判断しない一方、別の形で決定と承認の跡を示せなければ証拠不足になります。

アジャイルで不足しやすいのは、要件の変更を誰がいつ承認したかと、リリースの判断が誰の責任で行われたかの2点です。チケット管理ツールの変更履歴、プルリクエストのレビューと承認の記録、CIのテスト結果、デプロイの実行記録を消さずに残しておけば、これらは書面に代わる証拠になります。

監査直前の書類づくりで失敗するパターンと委託契約で先に決める事項

監査の通知を受けてから記録を集め始めると、次のような形で行き詰まります。

  1. 承認日より後に作成された承認記録が見つかり、事後に作った書類だと判明する。
  2. 委託先の担当者が交代しており、変更の経緯を説明できる人がいない。
  3. ログの保存期間が監査対象期間より短く、期初の記録が消えている。
  4. 委託先が記録を持っているが、契約上の提出義務がなく開示を断られる。

4番目は契約で防ぐしかありません。委託契約や保守契約の段階で、変更記録とログを誰がどの形式で何年残すか、監査時に委託先が資料提出とインタビューに応じるかを決めておきます。日々の運用業務のどこで記録が生まれるかはシステム運用の業務一覧と委託判断の考え方で整理済みです。記録を残す運用そのものを外部に任せる場合は、保守運用・内製化支援のように、作業報告と変更記録の提出まで含めて請け負う委託先を選ぶと、監査前の書類づくりを大きく減らせます。

システム監査を実施すべき場面と見送って管理の整備を先にすべき場面の判断

任意監査である以上、いつ、どの型で実施するかは依頼する側が決めます。

J-SOXのIT統制評価や委託元からの要請があるときは保証型を先に選ぶ

上場企業や上場準備企業で、財務報告に関わる内部統制のうちITへの対応を評価する必要があるなら、システム監査の結果を評価の材料に使えます。経済産業省はシステム管理基準と財務報告に関わるIT統制との対応関係を示す「システム管理基準 追補版(財務報告に係るIT統制ガイダンス)」を令和6年12月25日に改訂しており、システム監査制度のページから入手できます。IT業務処理統制と全般統制の区別はITACとITGC・ITDMの違いを整理した記事を参照してください。

取引先から管理レベルの証明を求められている受託事業者も、保証型を選ぶ場面です。結論が第三者に渡るため、対象範囲は取引先の関心に合わせて切ります。

監査を入れても効果が出ない条件と管理の整備から始めるべき組織の判断

次の条件に当てはまる組織では、保証型の監査はまだ早いと判断します。規程や手順書が無い、システムの一覧と担当者が把握できていない、変更の承認ルールが定まっていない、のいずれかです。この状態で監査を受けても、報告書はほぼ全項目が指摘事項になり、改善の優先順位すら読み取れません。

こうした組織は、システム管理基準のITマネジメント編から自社に必要な項目を選んで社内規程に落とし、半年ほど運用して記録を貯めることから始めます。そのうえで助言型の監査を受け、指摘を潰してから保証型に進む。逆に、記録が揃っているのに助言型を繰り返すのは過剰で、保証型に切り替えて結論を経営判断や取引先への説明に使う段階に来ています。

よくある質問

システム監査を初めて検討する担当者から出ることの多い質問に、原文の記載をもとに答えます。

システム監査は法律で義務付けられていますか?

義務付けられていません。基準3はシステム監査を法令等で義務付けられていない任意監査と位置づけ、そのぶん依頼者のニーズを法定監査以上に意識するよう求めています。ただし、財務報告の内部統制でITへの対応を評価する企業や、取引先から管理レベルの証明を求められる企業では、実施を迫られる場面があります。

システム監査基準とシステム管理基準はどちらを読めばよいですか?

監査を受ける側はシステム管理基準を先に読みます。各項目に達成目標と管理活動の例が並ぶため、自社の点検表として使えるからです。システム監査基準は、監査の手順と証拠の要件を知りたいときに読む文書で、どちらも2023年4月26日付の版が現行です。

システム監査と情報セキュリティ監査の違いは何ですか?

対象と判断の物差しが違います。システム監査はITのガバナンス、マネジメント、コントロール全体を対象とし、主にシステム管理基準を尺度にします。情報セキュリティ監査は情報セキュリティの管理に対象を絞る監査で、判断の尺度は情報セキュリティ管理基準です。システム監査基準の前文は、情報セキュリティの監査ではシステム管理基準とあわせて情報セキュリティ管理基準も参照するのが望ましいとしており、両者は重ねて使う関係にあります。

システム監査人になるには資格が必要ですか?

システム監査基準は、監査人になるための特定の資格を要件にしていません。監査人を監査役(会)等、内部監査人、外部の第三者を含む立場として定義し、基準2で教育や研修、実務経験を通じた知識と技能の保持を求めています。重視されるのは資格の有無より、監査テーマに合う知識を監査組織が総体として持っているかと、監査対象から独立しているかです。

開発を外部に委託している場合、委託先も監査の対象になりますか?

なり得ます。システム監査の対象にはITの外部委託の工程が含まれ、システム管理基準もⅡ.2.6外部委託管理とⅡ.8外部サービス管理で、委託先の選定、契約、検収、評価を管理項目に挙げています。監査人が委託先の記録を確かめる必要が出たときに提出を受けられるよう、委託契約で資料の提出義務と記録の保存期間を決めておくと、監査の場で詰まりません。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.08 テックブログ 大阪公立大学のランサムウェア被害と仮想化基盤の停止|全授業休講に至った経緯とバックアップを守る設定
  2. 2026.10.09 テックブログ IDCFクラウドの不正アクセスとランサムウェア被害|利用者の初動と別基盤への復旧手順
  3. 2024.11.08 テックブログ OpenAPI GeneratorでJavaコードを自動生成する方法|CLI導入からSpring・ライブラリ選択まで
  4. 2026.10.09 テックブログ ニッスイのサイバー攻撃で日水物流の入出荷停止|委託先クラウド障害に荷主が備える手順
  5. 2026.10.09 テックブログ 京王電鉄のランサムウェア被害とグループ共通基盤:決済・ポイント・予約が止まった範囲と遮断の初動

RELATED POSTS 関連記事

目次