監査で何を確かめ、どう改善する？——監査の種類・証拠・改善の分担｜支援士解説1の5

この記事の重要度：Cランク（主に午前II（科目A-2）で問われる論点。午後では問題文の前提として読めれば十分）

この記事で分かること：

• 情報セキュリティ監査・システム監査・内部監査・自己点検の違いと、監査人の独立性

• 監査計画書・監査調書・監査報告書・改善計画書の役割と、監査証拠・監査証跡の区別

• 委託先やクラウドサービスを監査で確かめるときの考え方

シラバスとの対応：小項目1-5「情報セキュリティ監査」。方針とISMSは支援士解説1の1、規程の整備は支援士解説1の4、委託先の管理は支援士解説3の10で扱います。

情報セキュリティ監査は、午後の大問の主題になることはほとんどありません。一方、午前IIでは、監査の種類、監査人の独立性、監査証拠や改善勧告の扱いが繰り返し問われます。また、午後の問題文には「内部監査室」「委託先を定期的に監査する」「監査報告書で確認する」といった前提がよく出てきます。

この記事では、監査を「決めた基準に照らして、証拠で評価し、改善につなげる活動」として整理します。見つかった問題を直すのは監査を受けた組織の仕事で、監査人は事実と根拠を報告し、改善の方向を助言します。この役割分担が、午前IIの多くの選択肢を見分ける軸になります。

1. 監査は「基準に照らして、証拠で評価する」

情報セキュリティ監査は、組織の情報セキュリティの管理や対策について、独立した立場で専門知識を持つ監査人が、証拠に基づいて客観的に評価する活動です。ISMSのPDCAサイクルでは、評価（Check）に当たります。

監査には、次の三つが欠かせません。

• 基準：何を満たすべきか。組織の情報セキュリティポリシー、契約、適用される法令、外部の管理基準など

• 証拠：基準を満たしているかを示す事実。規程、申請・承認の記録、設定の抽出結果、ログ、担当者への質問の結果など

• 範囲：どの組織・システム・期間を対象にしたか

「安全かどうかを調べる」だけでは、問いが広すぎます。たとえば「異動者の権限を、規程の期限内に変更しているかを、上期の記録で確かめる」と定めて初めて、何を集め、何に照らして判断するかが決まります。監査の結論は、定めた範囲と期間についてのものです。対象外のシステムや、将来に事故が起きないことまでは保証しません。

似た活動との違いも押さえます。

• 脆弱性診断：技術的な弱点を見つける検査。診断の結果は監査証拠の一つになり得るが、診断をした事実だけで、権限の承認や例外の管理が適切だとは言えない

• インシデントの調査：起きた事故の原因と影響を調べる活動。監査中に事故の兆候を見つけたら、報告書の完成を待たずに定めた経路で連絡し、事故対応へ切り替える（支援士解説4の3）

2. 監査の種類と、独立性

対象による区別

• 情報セキュリティ監査：機密性・完全性・可用性を守る管理の仕組みと対策を評価する。経済産業省の情報セキュリティ監査制度は2003年4月に始まった

• システム監査：ITシステムの利活用に関わるリスクへの対応を、ガバナンスやマネジメントの観点から評価し、保証や助言を行う。セキュリティだけでなく、企画・開発・運用・外部サービスの管理まで視野に入る

• 業務監査：受付、審査、支払などの業務の流れや内部統制を評価する

権限管理の不備のように、複数の監査で対象になる論点もあります。監査の名前で担当を切り分けるより、目的と範囲を読みます。

監査人の所属による区別

• 内部監査：組織内の監査部門などが行う

• 外部監査：組織の外の専門家が行う

「内部か外部か」は監査人の所属の違いで、「セキュリティかシステムか」は対象の違いです。内部監査として情報セキュリティ監査を行うこともあります。

自己点検は監査ではない

自己点検は、業務やシステムを運用する部門が、自らの実施状況を確かめる活動です。早く改善できる利点がありますが、自分が行った作業を自分で評価するだけなら、独立した監査にはなりません。

独立性は、監査人が自分の利害や被監査部門の都合に引きずられずに評価できることです。組織内の監査人でも、担当業務から分離され、必要な情報にアクセスでき、指摘を適切な相手へ報告できれば、内部監査を行えます。反対に、外部の専門家でも、自ら設計・運用した対策を自ら評価するなら、客観性が疑われます。

午後で出てくる場面

独立性は、午後でも短い設問で問われてきました。

• 平成27年度秋期 午後II問1（情報セキュリティスペシャリスト試験）：情報システム部がシステムの構築・運用とセキュリティ管理を担い、情報セキュリティ管理部がその状況を定期的に監査する、という条件が示された。監査とセキュリティ管理の役割を一つの組織に持たせた場合の不都合を問われ、解答例は、セキュリティ管理の状況を客観的に監査できない、という趣旨だった

• 平成23年度特別試験 午後II問2（情報セキュリティスペシャリスト試験）：外部の情報セキュリティ監査を題材に、助言型と保証型の区別や、開発委託先に監査を任せると独立性を確保しにくいことが問われた

監査人の行動の基準と、評価の尺度

経済産業省は、監査人の行動の基準と、評価に使う尺度を、別々の文書として示しています。

• 情報セキュリティ監査基準：監査人の行為規範。一般基準（監査人の適格性と守るべき事項）、実施基準（監査計画と監査手続の進め方）、報告基準（監査報告書の書き方）で構成される

• 情報セキュリティ管理基準：管理策を評価するときの尺度。ISO/IEC 27001・27002を基にしている

• システム監査基準（監査人の行為規範）とシステム管理基準（管理の実践規範）：2023年4月に改訂され、実施方法の細部はガイドラインに分けられた。システム監査基準は、守るべき原則として誠実性、客観性、能力と正当な注意、秘密の保持を挙げている

「監査基準」は監査人がどう行動するか、「管理基準」は何に照らして判断するか、と区別して覚えます。

3. 保証型と助言型、そしてISMS認証

情報セキュリティ監査には、結論の示し方が違う二つの形態があります。

• 保証型監査：監査手続を実施した範囲で、対象のマネジメントや管理策が適切である（又は適切でない）ことを、意見として表明する。第三者への説明に「お墨付き」が必要な場合に向く

• 助言型監査：問題点を検出し、必要に応じて改善提言を示す。組織が段階的に水準を上げていきたい場合に向く

経済産業省の令和7年改正版の監査基準では、この二つをアシュアランス型とアドバイザリー型と表記しています。自治体向けの監査ガイドラインのように、従来の「保証型・助言型」を使う資料もあるので、どちらの言葉でも読めるようにしておきます。

押さえておきたい点は三つです。

• 保証型の「保証」は、事故が起きないことの保証ではない。定めた対象・基準・手続の範囲での意見である

• 助言型だから水準が低い組織向け、保証型だから水準が高い組織向け、と機械的に決まるものではない。誰が何のために依頼し、結果を誰がどう使うかで選ぶ

• 助言型の改善提言を採用するかどうかは、監査を受けた組織が決める。監査人が採否を決めるわけではない

ISMS認証との違い：ISMS認証は、定めた適用範囲のマネジメントシステムが規格に適合しているかを、認証機関が審査する制度です（支援士解説1の1）。認証を取得していても、適用範囲の外のサービスや、その後に変わった業務は別に確かめる必要があります。反対に、認証がなくても、目的を定めた監査は行えます。

4. 監査の流れと四つの文書

監査は、一般に次の順で進みます。

1. 監査計画：目的、対象（部門・システム・期間）、判断の基準、方法、担当、日程、必要な資料、報告先を決める

2. 予備調査：対象の概要をつかみ、監査手続（証拠を得るための具体的な手順）を確定させる

3. 本調査：監査手続を実施し、監査証拠を集める

4. 評価・結論：集めた監査証拠を基準に照らして評価し、結論をまとめる

5. 監査報告：監査報告書で、結果、指摘、改善提言、範囲の制約を報告先に伝える

6. フォローアップ：改善が実施され、効果が出ているかを確かめる

この流れで作る文書は、作る人と目的が違います（図1）。

• 監査計画書：これから何を、何に照らして、どう監査するか

• 監査調書：監査人が実施した手続、集めた証拠の出所、判断、例外、結論の限界の記録。監査意見の根拠になる。監査人が自ら作成した資料も含む

• 監査報告書：対象、方法、基準、結果、指摘・提言、確認できなかった範囲を報告先へ伝える

• 改善計画書：指摘を受けた組織が、何を、誰が、いつまでに直し、どう確かめるかを決める。作るのも実施するのも、監査を受けた組織

監査計画では、扱う情報の重要性、変更の頻度、過去の事故や指摘などから、重点を置く対象を選びます（リスクに基づく監査）。ただし、対象外にした範囲は記録し、結果を組織全体へ広げません。

指摘と改善勧告の書き方

指摘は、基準、確認した事実、根拠、影響、改善の方向の順に書くと、読んだ人が再確認できます。午前でよく問われるのは次の点です。

• 改善勧告は、監査証拠に裏付けられたものでなければならない

• 報告の前に、調査結果に事実誤認がないかを被監査部門に確認する。誤りが見つかれば修正する

• ただし、指摘を載せるのに被監査部門の承認や同意は要らない。十分な証拠がある指摘を、同意がないという理由で削らない

• 改善の実現可能性も考える。業務や予算の制約を無視した勧告は、改善につながらない

監査調書には、個人情報やシステムの弱点が含まれることがあります。閲覧できる人、保存期間、受け渡しの方法を管理します。

5. 監査証拠と監査証跡

監査証拠は、監査人の判断を裏付ける情報です。教科書では、次のように分類されます。

• 物理的証拠：監査人が現場で直接確かめたもの（入退室の管理の観察など）

• 文書的証拠：規程、申請書、承認記録、ログ、設定の一覧など

• 口頭的証拠：担当者への質問の回答

担当者の説明（口頭的証拠）も証拠になります。ただし、それだけで結論を出さず、記録や設定と照合して裏付けます。

証拠は量より、問いとの関係と信頼性が大切です。

• 抽出した人、抽出条件、取得日時、対象期間を確かめる。スクリーンショットは一時点しか示さず、CSVはフィルタで内容が変わる

• 全件を調べられないときは、母集団と抽出の方法を記録する。抽出した10件に不備がなかったという結果は、その10件についての確認であり、根拠なく全体へ広げない

• 「ログに見当たらない」には、操作がなかった場合と、ログが取れていない・残っていない場合がある。後者を確かめずに前者と結論しない

• ログに利用者IDの操作が残っていても、本人が操作したか、業務上の許可があったかまでは、その一行で決まらない

監査証跡は、処理の過程を後からたどれるようにする仕組みや記録です。時刻、利用者、対象、操作、結果を結び付けられるログが典型です。監査証跡があって初めて、監査証拠を取ることができます。ログの設計と保管は支援士解説3の4で扱います。

午前I（高度試験の共通問題）では、データベースを特権IDで直接修正した事例の中から「報告すべき指摘」を選ぶ問題が出たことがあります。直接修正の更新ログを、アプリケーションを通した通常の更新として記録していた、というように監査証跡そのものが事実と違う状態は、重大な指摘になります。事前・事後の承認や、作業後の特権IDの無効化は、むしろ適切な管理の例です。

支援士の役割：監査人がログやクラウドの設定を読むとき、技術に詳しい人の支援が必要になることがあります。権限一覧の抽出条件、ログの保存範囲、時刻のタイムゾーン、委託先の操作がどの記録に残るかを説明する仕事です。監査チームの専門家として加わっても、結論に責任を持つのは監査人です。被監査部門の担当者として資料を出す場合は、都合の悪い行を除かず、抽出条件と欠落を正確に伝えます。

6. 改善計画とフォローアップ

指摘を受けた組織は、改善計画を作ります。次のように分けると、実行と確認がしやすくなります。

• すぐに行う措置：残っていた不要な権限の停止など、見つかった問題そのものへの対処

• 原因への対応：申請の受付ではなく、実際の設定の変更が完了したことを確かめる手順に直す、など再発を防ぐ対処

• 有効性の確認：次の異動の時期に、期限内に変更され、別の担当者が確認したかを確かめる

この分け方は、ISMSの「修正」と「是正処置」の区別と同じ考え方です（支援士解説1の1）。

フォローアップでは、「対応完了」という報告と、管理策が実際に働くようになったことを分けて確かめます。規程は直したが設定が変わっていない、設定は変えたが未処理の人が残っている、といった状態を見分けます。

どの対策を採用し、予算と期限をどう配分し、残るリスクを誰が受け入れるかは、権限を持つ組織の側が判断します。監査人は、改善提言の根拠と、採用しなかった場合に残る問題を明確に示します。

7. 委託先とクラウドサービスを監査で確かめる

業務を委託しても、委託元の責任はなくなりません。契約で求めた管理が実際に行われているかを、監査などで確かめます。委託先の選定から終了までの管理は支援士解説3の10で扱い、ここでは監査に関わる点に絞ります。

契約で監査の権利と方法を決めておく

• 委託元が監査できること（監査権）を契約に入れる。対象範囲、時期、方法（現地・書面・遠隔）、提出してもらう資料、再委託先の扱いまで決めておく

• 監査条項があっても、範囲や手順が決まっていなければ、必要なときに確かめられないことがある

直接監査できないときは、第三者の報告で確かめる

• 共用のクラウドサービスでは、他の利用者の保護のために、利用者ごとの立入りが難しいことが多い。その場合は、第三者による監査報告書や保証報告書（SOC 2など。支援士解説2の2）、ISMS認証、政府情報システムのためのISMAPの登録などを材料にする

• 材料を使うときは、報告書や認証の対象サービス・範囲・期間が、自組織が使うサービスと一致するかを確かめる。利用者が行う設定は、事業者の報告書の評価の外に残る

• それでも重大な不確実性が残るなら、利用範囲を限定する、別のサービスを選ぶ、といった判断につなげる

午後で出てくる場面

委託先の監査は、午後では問題文の前提や、対策を答える設問に出てきます。

• 平成27年度秋期 午後II問2（情報セキュリティスペシャリスト試験）：委託先との契約で目的外利用の禁止と適切な管理を求めていたが、調査すると委託先の管理が不十分だった。内部不正防止のガイドラインを参考にまとめた対策が問われ、解答例は、委託先のデータ管理の実態を監査で把握して監督する、という趣旨だった。契約で求めることと、実態を確かめることは別だという論点

• 令和2年度10月 午後II問2：クラウドサービスの事業者のセキュリティ対策を、利用者が直接確かめられない場面で、第三者による監査報告書で確認する方法が問われた

• 令和7年度春期 午後問1：セキュリティ監視を委託している情報セキュリティ会社（運用ツールなど一部のソフトウェアの開発も行うことがある）との契約に、委託先内の実施事項と再委託の禁止を明記し、契約の順守状況を定期的な監査で確かめる、という管理が問題文の前提に示された

• 令和7年度秋期 午後問4：取引先との契約に、秘密保持の状況について取引先の監査を受ける義務が含まれている、という前提が示された。自社が監査を受ける側になる場面

8. 午前II（科目A-2）で正誤を見分けるポイント

• 「監査の結果、問題がなければ将来の事故は起きないと保証される」→ 誤り。定めた範囲・期間・基準についての評価

• 「運用担当者が自分の設定をチェックリストで確かめれば、内部監査になる」→ 誤り。それは自己点検。監査には独立性が必要

• 「内部監査は、組織内の人が行うので独立性は問われない」→ 誤り。被監査部門から独立していることが必要

• 「助言型監査では、改善提言の採否を監査人が決める」→ 誤り。採否は監査を受けた組織が決める

• 「改善勧告は、監査人が必要と判断すれば、証拠の裏付けがなくても記載できる」→ 誤り。監査証拠による裏付けが必要

• 「改善勧告は、被監査部門の責任者が承認した事項だけを記載する」→ 誤り。事実誤認の確認はするが、承認は要らない

• 「監査調書は、監査を受けた部門が作成する」→ 誤り。監査人が作成する。改善計画書は監査を受けた組織が作る

• 「監査証跡となるログがあれば、監査証拠として十分である」→ 誤り。問いとの関係、完全性、取得の経緯を確かめる

• 「担当者への質問の回答は、監査証拠にならない」→ 誤り。口頭的証拠になる。ただし記録などで裏付ける

• 「情報セキュリティ管理基準は、監査人の行為規範である」→ 誤り。行為規範は監査基準。管理基準は評価の尺度

• 「ISMS認証を取得していれば、情報セキュリティ監査は不要である」→ 誤り。目的、範囲、結論の性質が違う

理解度チェック

本文の理解を確かめるためのオリジナル問題です。実際の過去問ではありません。

問1　内部監査と自己点検

申請サービスの運用担当者が、自分で設定した権限をチェックリストで確かめた。この活動の説明として、最も適切なものはどれか。

• ア：外部監査である。専門的な設定を見ているため

• イ：独立した内部監査である。チェックリストを使っているため

• ウ：自己点検である。運用者が自分の担当する設定を確かめているため

• エ：業務監査である。権限は業務に関係するため

正解：ウ。確かめる対象が技術的でも、自分の作業を自分で評価するなら自己点検です。アは所属、イは独立性、エは監査の対象を取り違えています。

問2　改善勧告

監査報告書に記載する改善勧告の説明として、最も適切なものはどれか。

• ア：監査人が必要と判断した事項なら、監査証拠の裏付けがなくても記載する

• イ：被監査部門の責任者が承認した事項だけを記載する

• ウ：調査結果に事実誤認がないことを被監査部門に確かめた上で、監査人が改善の必要があると判断した事項を記載する

• エ：改善の実現可能性は考えず、理想的な対策だけを記載する

正解：ウ。勧告は監査証拠に裏付けられている必要があります（ア）。被監査部門の承認は要りません（イ）。実現可能性も考えます（エ）。

問3　監査証拠

異動日の翌日に、異動した職員の利用者IDで申請情報を閲覧したログが見つかった。監査人の対応として、最も適切なものはどれか。

• ア：本人による不正な閲覧と断定し、報告書に記載する

• イ：利用者IDが使われた事実を押さえ、ログの記録範囲、例外の承認、引継ぎの状況などを追加で確かめる

• ウ：認証に成功しているので、業務上も正当な閲覧だったと判断する

• エ：ログが1件だけなので、権限管理の全体に問題はないと判断する

正解：イ。ログが示す事実と、それだけでは決まらないことを分けます。アは人物と意図を即断し、ウは認証の成功と業務上の許可を混同し、エは1件から全体へ結論を広げています。

問4　クラウドサービスの確認

利用するクラウドサービスの事業者の管理を確かめたいが、利用者による立入りは認められていない。最も適切な対応はどれか。

• ア：立入りできないので、確認は不要と判断する

• イ：第三者による監査報告書や認証を入手し、対象のサービス・範囲・期間が利用するサービスと一致するかを確かめる

• ウ：事業者が認証を取得していれば、利用者側の設定も適切だと判断する

• エ：立入りできないサービスは、どんな条件でも利用しない

正解：イ。直接確かめられない場合も、第三者の報告で確かめる方法があります（ア）。認証は利用者の設定までは評価しません（ウ）。エのように両極端に決めず、対象に合う確認の方法と、残るリスクで判断します。

実務と国・自治体では

• 経済産業省の監査基準：令和7年改正版の情報セキュリティ監査基準・管理基準が公表されている。監査人の行為規範と、評価の尺度を分けて読む。経済産業省「情報セキュリティ監査制度」

• 政府機関等の統一基準：監査責任者が監査を計画・実施し、結果を最高情報セキュリティ責任者（CISO）に報告する。CISOは指摘への改善計画の策定などを指示し、進捗の報告を求める。政府機関等向けの基準なので、自治体や企業に同じ条項がそのまま義務として当てはまるわけではない（統一基準群の位置付けは支援士解説1の1）

• 自治体向けの監査ガイドライン：総務省「地方公共団体における情報セキュリティ監査に関するガイドライン」は、内部監査と自己点検の区別、計画、証拠、報告、改善、フォローアップの流れを示している。緊急性の高い指摘は速やかに対応し、それ以外はフォローアップ監査で確かめる。監査結果の公開は、情報公開条例の不開示情報の扱いなどを踏まえて範囲を判断する。総務省「地方公共団体における情報セキュリティ監査に関するガイドライン」

実務では、監査のために証拠を作り直さないことが大切です。後から整えた記録は、当時の運用を示しません。契約上、委託先から得られなかった資料は、次の契約で求める項目として残します。

まとめ

• 監査は、基準・証拠・範囲がそろって成り立つ。 結論は定めた範囲についてのもので、将来の無事故の保証ではない。

• 自己点検と監査は別。 内部監査でも、被監査部門からの独立性が必要。

• 監査調書は監査人、改善計画書は監査を受けた組織が作る。 改善勧告は証拠で裏付け、事実誤認は確かめるが承認は要らない。

• 委託先は、契約で監査の権利と方法を決め、直接確かめられなければ第三者の報告の範囲を照合する。

さらに深く学ぶなら

この記事の範囲を超えて、仕組みをもっと深く知りたい人向けの本です（試験対策の本ではありません）。

• 脅威インテリジェンスの収集・分析・活用・共有を、フレームワークとともに体系的に学べる

関連記事

• 前提：情報セキュリティ方針は、何を守り、誰が決める？｜支援士解説1の1（ISMS・内部監査・是正処置）

• あわせて読む：そのルールでセキュリティ担当者は動ける？｜支援士解説1の4（監査の基準になる規程）

• あわせて読む：委託すれば、任せて安心？｜支援士解説3の10（委託先の選定から終了までの管理）

• あわせて読む：その製品、安全に使えますか？｜支援士解説2の2（クラウドサービスの評価と第三者の保証報告書）

2026年10月改訂：午前IIで問われる監査の種類・文書・証拠・改善勧告に絞り、委託先とクラウドサービスの監査の節を加えました。